증상부터: 왜 AI 검색·연구 도구만 유난히 느릴까
일반 웹 서핑은 무난한데 Perplexity에서 답변이 한참 걸리거나, Google NotebookLM에서 소스를 붙일 때만 업로드 진행이 멈추고, 반대로 로그인 화면만 반복된다면 먼저 의심할 것은 「노드가 전부 나쁘다」만은 아닙니다. 최근 AI 검색·요약·연구 보조 제품은 브라우저 탭 하나처럼 보이지만, 실제로는 여러 호스트로 나뉜 트래픽이 동시에 흐릅니다. 그중 일부는 직접 연결이 빠르고, 일부는 안정적인 중계가 필요한 경우가 흔합니다.
전역 프록시를 켠 채로 쓰면 모든 요청이 같은 경로를 타기 때문에, 특정 CDN 구간만 지연이 크거나 SNI·TLS 협상이 까다로운 구간이 섞일 때 체감 속도 전체가 떨어집니다. 반대로 거의 전부 직접 연결로 두면, API나 인증 게이트웨이만 막혀 질문은 되는데 파일 처리만 실패하는 식의 부분 장애가 납니다. 이 글은 코딩 IDE용 스택(Cursor·GitHub 분류 글에서 다룬 흐름)과 겹치지 않게, 브라우저 중심의 AI 검색·연구 시나리오에 초점을 맞춥니다.
네트워크 정책과 법규는 지역·기관마다 다릅니다. 본문은 기술적 분류·연결 경로 설명에 한정하며, 허용된 용도와 본인 책임 범위 안에서만 적용하시기 바랍니다. Clash 계열의 기본 개념은 Clash 사용 문서와 함께 보면 이해가 빠릅니다.
웹·API·CDN·인증: 한 서비스가 여러 도메인을 쓰는 이유
연구형 AI 도구는 대개 다음 네 가지 축으로 트래픽이 갈라집니다. 첫째, 사용자가 보는 웹 앱 본체 도메인. 둘째, 질의·스트리밍 응답을 주고받는 백엔드 API 호스트. 셋째, 스크립트·이미지·폰트를 실어 나르는 정적 자원·CDN. 넷째, Google 계정 연동처럼 OAuth·세션·토큰을 다루는 인증 계열 도메인입니다.
Clash 관점에서는 이 네 축이 서로 다른 SNI·IP 풀로 풀릴 수 있어, 한 축만 잘못된 정책에 걸려도 화면은 뜨는데 질의만 멈추는 현상이 생깁니다. 특히 CDN은 지역별 PoP에 따라 같은 파일이라도 다른 서브도메인으로 나뉘기도 하므로, 증상이 간헐적일수록 도메인 목록을 로그로 확인하는 것이 안전합니다.
또한 HTTP/2·WebSocket에 가까운 긴 연결을 쓰는 API는 중간 프록시의 유휴 타임아웃·버퍼 정책과 맞물리기 쉬워, 「빠른 노드」라도 스트리밍 응답에는 맞지 않는 경우가 있습니다. 이때는 속도 테스트 점수만 보기보다, 해당 호스트를 지연보다 안정성 우선 그룹으로 묶는 편이 낫습니다.
Perplexity 쪽에서 자주 보이는 호스트 패턴
Perplexity는 제품·리전·기능 플래그에 따라 호스트가 바뀔 수 있으므로, 아래는 출발점으로만 쓰고 실제 운영에서는 클라이언트 로그를 기준으로 다듬으세요. 흔히 웹 UI는 perplexity.ai 계열에 묶이고, API·에셋·추적·실험 기능은 별도 서브도메인이나 제3자 CDN으로 이어지는 경우가 있습니다.
- 메인 앱·검색 UI: 브라우저 주소창에 보이는 최상위 도메인과 그 하위 호스트.
- API·스트리밍: 질의 전송과 토큰 스트림을 담당하는 호스트로, UI와 다른 접두사를 쓰는 경우가 많습니다.
- 정적 리소스: JS 번들·아이콘·미디어가
cdn·static류 서브도메인이나 글로벌 CDN 브랜드 도메인으로 분리될 수 있습니다.
한 줄 요약하면, 「Perplexity 한 줄 규칙」으로 끝내기보다 실패한 요청의 호스트 이름을 한 줄씩 규칙 상단에 추가하는 방식이 유지보수 비용을 줄입니다. 외부 RULE-SET으로 묶고 싶다면 Rule Provider 가이드의 패턴을 참고해 별도 provider 파일로 관리하세요.
NotebookLM·Google 생태에서 빠지기 쉬운 인증·API 축
NotebookLM은 Google 계정과 강하게 묶여 있어, 앱 자체 도메인만 프록시에 올려 놓고 accounts.google.com·oauth·쿠키 도메인을 그대로 두면 로그인 루프나 권한 오류가 날 수 있습니다. 반대로 Google 전체를 한꺼번에 같은 그룹에 넣으면, 검색·유튜브·드라이브까지 한꺼번에 경로가 바뀌어 원하지 않는 부작용이 생기기도 합니다.
실무에서는 (1) NotebookLM 앱 호스트, (2) 질의·문서 처리 API에 해당하는 호스트, (3) 로그인·토큰 교환에 필요한 최소한의 Google 인증 호스트를 같은 정책 그룹에 두되, 나머지 Google 서비스는 기존 프로필 규칙을 따르게 범위를 좁게 잡는 접근이 균형이 좋습니다. 정확한 목록은 제품 업데이트마다 달라지므로, 증상이 난 시점의 로그를 한 번 캡처해 두는 습관이 중요합니다.
기업·교육 기관 계정에서는 추가적인 디바이스 인증·정책 체크 도메인이 붙을 수 있습니다. 이때는 보안 정책상 분할 터널 자체가 제한될 수 있으니, 내부 가이드를 먼저 확인하세요.
전용 proxy-groups 설계: AI_SEARCH를 IDE 그룹과 분리하기
이미 AI_DEV 같은 개발자 전용 그룹을 쓰고 있다면, AI 검색·연구용으로 AI_SEARCH(이름은 임의)를 별도로 두는 것을 권합니다. 이유는 단순합니다. IDE 트래픽은 대용량 패키지·Git LFS·마켓플레이스처럼 다운로드 성격이 강하고, Perplexity·NotebookLM은 짧은 왕복이 잦은 API와 스트리밍이 중심입니다. 같은 그룹에 넣으면 url-test 기준이 한쪽에만 맞춰져 다른 쪽이 불안정해질 수 있습니다.
AI_SEARCH에는 보통 fallback이나 완만한 임계값의 url-test, 혹은 수동 선택형 select를 올려 두고, 지연 숫자만 보지 말고 끊김 빈도를 기준으로 노드를 고릅니다. 스트리밍 응답이 중간에 끊기면 사용자는 「느리다」보다 「망가졌다」로 인식하기 때문입니다.
YAML 스케치: DOMAIN 규칙을 좁은 예외로 위에 쌓기
아래는 이해를 돕기 위한 축약 예시입니다. 실제 도메인은 본인 환경의 로그로 교체하고, AI_SEARCH는 프로필 안의 proxy-groups 이름과 맞추세요. 코어·GUI에 따라 지원 키워드가 다를 수 있습니다.
# AI search / research tools — keep narrow rules above broad GEOIP / RULE-SET (comments in English per project convention)
proxy-groups:
- name: AI_SEARCH
type: select
proxies:
- PROXY_NODE_A
- PROXY_NODE_B
- DIRECT
rules:
- DOMAIN-SUFFIX,perplexity.ai,AI_SEARCH
- DOMAIN-SUFFIX,pplx.ai,AI_SEARCH
- DOMAIN-SUFFIX,google.com,AI_SEARCH
- DOMAIN-SUFFIX,googleusercontent.com,AI_SEARCH
- DOMAIN-SUFFIX,gstatic.com,AI_SEARCH
- DOMAIN-SUFFIX,googleapis.com,AI_SEARCH
# Add notebooklm.* / generative language hosts from your logs; avoid unrelated Google video CDN
# Add only hosts your NotebookLM session actually hits; avoid blanket GOOGLE if possible
- MATCH,PROXY_OR_FALLBACK위 예시에서 Google 관련 줄은 의도적으로 넓게 잡히므로, 실사용에서는 NotebookLM 세션에서 실제로 보이는 호스트만 남기고 나머지는 제거하는 것이 좋습니다. 그렇지 않으면 「AI 검색만 분리」라는 목적이 흐려져 다른 Google 트래픽까지 한 그룹으로 몰릴 수 있습니다. MATCH 한 줄은 기존 프로필의 마지막 규칙 자리를 가정한 것이며, 실제 파일에서는 이미 쓰는 GEOIP·RULE-SET 순서를 유지한 채 AI 검색 블록만 위쪽에 끼워 넣으세요.
규칙 순서와 충돌: 첫 매칭이 이기고, 넓은 RULE-SET이 삼킨다
Clash 계열은 rules를 위에서 아래로 읽다가 처음 맞는 한 줄에서 결정합니다. 따라서 Perplexity용 예외를 추가했는데도 효과가 없다면, 그보다 위에 있는 더 넓은 DOMAIN-KEYWORD나 대형 RULE-SET이 먼저 매칭되는지 확인해야 합니다.
또 한 가지, GEOIP,CN,DIRECT 같은 규칙이 AI 도구가 붙는 IP 대역을 국내로 오인하면, 의도와 반대로 직접 연결로 떨어질 수 있습니다. 이때는 로그의 실제 목적지와 GeoIP 결과를 대조해, 필요하면 DOMAIN 기반 예외를 GEOIP보다 위에 두세요. 다만 사내망·결제·은행 앱 직통처럼 더 좁고 민감한 예외는 그보다 또 위에 두는 것이 안전합니다.
DNS·fake-ip: 멀티 도메인일수록 같이 봐야 할 이유
같은 서비스라도 DNS 응답이 캐시·모드에 따라 다른 IP로 풀리면, 규칙은 맞는데 체감만 나쁜 상황이 연출됩니다. 특히 fake-ip를 쓰는 프로필에서는 도메인 규칙과 DNS 처리 순서가 맞물리므로, AI 검색만 느릴 때는 DNS 섹션과 Clash 로그를 함께 보는 것이 좋습니다. 누수·모드 선택은 DNS 누수 방지 가이드에 단계별로 정리되어 있습니다.
브라우저 확장 프로그램이 자체 DNS를 쓰거나, DoH를 우회로 붙이면 Clash가 보는 트래픽과 앱이 해석한 IP가 어긋날 수 있습니다. 증상이 브라우저에만 국한되면 확장·실험 플래그부터 끄고 재현해 보세요.
검증 루틴: 로그로 호스트를 모으고 한 변수씩 줄이기
규칙을 바꾼 뒤에는 다음 순서를 추천합니다. 첫째, 동일한 질문·동일한 첨부 업로드를 반복하며 로그에 남는 호스트 이름을 목록으로 모읍니다. 둘째, 문제 호스트만 임시로 다른 그룹이나 DIRECT로 옮겨 한 번에 한 변수만 바꿉니다. 셋째, 스트리밍 응답이 중간에 끊기면 노드 교체뿐 아니라 해당 API 도메인을 keep-alive에 유리한 프로필과 짝지었는지도 봅니다.
체감 지연을 줄이는 일반 튜닝은 속도 최적화 팁과 병행하면 좋습니다. 다만 AI 검색은 대역폭보다 왕복 지연·끊김이 체감에 더 크게 작용하는 경우가 많습니다.
보안·컴플라이언스 메모
회사망·학교망에서는 분할 터널·사용자 정의 규칙이 정책 위반일 수 있습니다. RULE-SET·원격 구독 URL은 외부 정책을 끌어오는 통로이므로 출처를 검증하지 않으면 민감한 트래픽이 예기치 않은 경로로 나갈 위험이 있습니다. 팀 단위로 쓸 때는 허용 도메인을 문서화하고 변경 시 리뷰를 거치는 편이 안전합니다.
오픈 소스 코어의 이슈와 릴리스는 Mihomo GitHub 저장소에서 확인할 수 있습니다. 클라이언트 설치 패키지는 배포 신뢰를 위해 공식 다운로드 페이지를 우선하는 편이 좋습니다.
정리
Perplexity·NotebookLM 같은 AI 검색·연구 도구는 단일 도메인 앱이 아니라 웹·API·CDN·인증이 얽힌 묶음입니다. Clash의 강점은 이 묶음을 도메인·IP 단위로 나누어 각각에 맞는 정책 그룹을 주는 데 있으므로, 전역 스위치에만 의존하기보다 AI_SEARCH 전용 규칙 블록을 설계하고 IDE용 그룹과 분리하는 편이 안정적입니다.
규칙형 클라이언트는 한번 구조를 잡아 두면 브라우저 기반 AI 도구와 일상 트래픽이 섞인 환경에서도 정책을 한눈에 유지하기 쉽습니다. 다른 범용 도구에 비해 Clash는 규칙 순서와 그룹 설계만 정리돼 있어도 체감이 확 달라지는 편입니다.