왜 Perplexity·AI 검색은 따로 DOMAIN-SUFFIX 묶음이 필요할까요?
생성형 검색 서비스는 (1) 로그인·설정·랜딩 페이지, (2) 실제 질의·스트리밍·툴 호출, (3) 미리보기·썸네일·인용 아이콘이 가리키는 CDN, (4) 단축·공유·추적용 별도 호스트로 쉽게 갈라집니다. OpenAI·Google·xAI·Anthropic용으로 이미 규칙을 나눠 두었다 해도, Perplexity가 쓰는 perplexity.ai·pplx.ai 등 접미사는 다른 글의 목록에 없을 수 있어 «전역 프록시면 되지 않나?»라는 기대와 달리 일부 트래픽만 국내 직행하거나 반대로 불안정한 노드로 새기 쉽습니다.
Clash에서는 호스트 단위로 정책 그룹을 지정할 수 있으므로, «AI 검색 업무»만 지연·가용성이 좋은 노드로 보내고 나머지 트래픽은 기존 규칙을 유지하는 구성이 가능합니다. 핵심은 (1) 실패한 요청의 SNI·호스트를 로그나 개발자 도구로 수집하는 것, (2) rules에서 그 호스트가 어떤 줄에 걸리는지 확인하는 것, (3) GEOIP·MATCH보다 위쪽에 Perplexity 예외를 두는 것입니다.
자주 보이는 증상: 웹은 되는데 «반쯤»만 되는 패턴
아래는 모두 «프록시가 완전히 틀렸다»만은 아니며, 규칙 순서·DNS·노드 품질·앱이 시스템 프록시를 안 탐이 겹칠 때도 비슷하게 나타납니다.
1) 랜딩·설정은 열리는데 질문 전송·스트리밍만 실패
초기 HTML·정적 자바스크립트는 한 경로로 가고, 이후 XHR·SSE·WebSocket이 다른 서브도메인이나 경로로 붙으면 첫 화면만 정상처럼 보입니다. 브라우저 개발자 도구의 Network 탭에서 실패한 요청의 호스트를 확인하고, Clash 로그의 «matched」 줄과 대조하세요.
2) 출처·인용·미리보기 이미지·아이콘만 비거나 느림
텍스트 응답은 오는데 카드 썸네일·파비콘·외부 링크 프리뷰가 비는 경우, 본문 도메인과 CDN·이미지 프록시 도메인이 규칙상 갈라진 경우가 많습니다. 로그에 새로 뜬 접미사가 있으면 DOMAIN-SUFFIX 줄을 한 줄씩 추가하는 방식이 유지 보수에 유리합니다.
3) 모바일 앱은 되는데 데스크톱 브라우저만 이상
앱이 자체 TLS·캐시·푸시 채널을 쓰면 시스템 프록시·TUN과 조합이 달라질 수 있습니다. 동일 계정으로 웹만 재현되면 브라우저 확장·프로필별 프록시·기업 SSL 검사를 함께 의심하세요.
4) 단축 링크·공유 URL만 열리지 않음
pplx.ai 등 단축·리다이렉트용 접미사가 메인 앱과 다를 수 있습니다. DOMAIN-SUFFIX,perplexity.ai만 있고 여기는 빠지면 «링크만 깨짐»처럼 보입니다.
복사해 쓰기 전에 확인할 Perplexity·관련 도메인 묶음
아래는 실무에서 자주 출발점으로 삼는 예시 목록입니다. 제품 업데이트·실험 기능에 따라 실제로 나가는 호스트는 달라질 수 있으므로, 반드시 본인 환경의 로그로 검증·추가하세요. DOMAIN-SUFFIX는 호스트 끝이 일치하면 매칭됩니다.
- perplexity.ai — 메인 웹·앱·API가 붙는 대표 접미사. 한 줄로
DOMAIN-SUFFIX,perplexity.ai,PERPLEXITY형태가 대부분의 «perplexity.ai로 끝나는» 요청을 덮습니다. - pplx.ai — 단축·공유·리다이렉트 등에 쓰이는 경우가 있어, 링크만 실패하면 별도
DOMAIN-SUFFIX,pplx.ai줄을 검토합니다. - 서브도메인 예시 —
www.·앱 전용·내부 API 등은 모두 위 접미사 아래로 묶이는 경우가 많지만, 특정 실험 호스트가 다른 루트 도메인을 쓰면 로그에 나온 대로DOMAIN,한 줄을 추가합니다.
DOMAIN-KEYWORD,perplexity처럼 짧게 쓰면 오탐이 늘 수 있어, 가능하면 접미사·정확 호스트를 우선합니다. 범용 RULE-SET을 쓰는 경우에도 AI 검색 전용 세트가 없다면 동일한 증상이 남을 수 있습니다.
OpenAI·Google 전용 규칙과 겹치지 않게 쓰기
같은 프로필에 ChatGPT·Gemini용 블록이 있다고 해서 Perplexity 트래픽이 자동으로 포함되지는 않습니다. 제품마다 도메인 축이 다르므로, 본 글은 그 격차를 메우는 Perplexity 전용 절을 목표로 합니다. OpenAI·Google 쪽 세부는 각각 ChatGPT·OpenAI 분기, Gemini·AI Studio 분기 글과 짝을 이룹니다.
rules 예시: PERPLEXITY 정책 그룹으로 보내기
아래는 개념을 보여 주는 최소 스니펫입니다. 앞쪽에 LAN·국내 직행이 있다고 가정하고, Perplexity 관련 접미사를 PERPLEXITY 그룹으로 보냅니다. 프로필마다 그룹 이름은 다르니 자신의 YAML에 맞춰 바꿔 쓰면 됩니다.
rules: - DOMAIN-SUFFIX,perplexity.ai,PERPLEXITY - DOMAIN-SUFFIX,pplx.ai,PERPLEXITY # 로그에서 확인된 추가 호스트는 DOMAIN 또는 DOMAIN-SUFFIX로 한 줄씩 # ... 기존 GEOIP·MATCH 등
PERPLEXITY는 proxy-groups에 정의되어 있어야 하며, 이름이 다르면 rules 인자도 동일 문자열로 통일해야 합니다. 규칙 모드·프로바이더 캐시·머지 순서는 YAML 규칙 분기 가이드의 설명과 맞춰 읽는 것이 좋습니다.
규칙 순서가 바뀌면 왜 «일부만» 깨지나요?
Clash는 같은 요청에 여러 줄이 해당되어도 위에서 아래로 첫 매칭만 적용합니다. 넓은 GEOIP나 최종 MATCH가 Perplexity 전용 줄보다 위에 있으면, 정적 페이지는 통과해 보여도 스트리밍·XHR만 다른 아웃바운드로 나가 차단·타임아웃처럼 보일 수 있습니다. 스트리밍·메신저·사내 예외가 많은 프로필일수록 서비스별 세부 줄을 포괄 규칙보다 위에 두는 습관이 필요합니다.
정책 그룹 설계: AI 검색 전용 출구 만들기
분기 규칙이 가리키는 것은 결국 어떤 노드 묶음으로 나갈지입니다. 일반 해외 프록시용 select와 별도로 PERPLEXITY 그룹을 두면, 일상 브라우징과 Perplexity·다른 AI 검색 워크로드를 노드 품질에 맞게 나눌 수 있습니다. url-test를 쓸 때는 테스트 URL이 특정 지역에서만 열리면 오탐이 나므로, 가벼운 공용 응답을 쓰는 편이 안전합니다.
proxy-groups: - name: "PERPLEXITY" type: select proxies: - "저지연-안정" - "백업" - "DIRECT" - name: "저지연-안정" type: url-test proxies: - # 구독에서 받은 노드 이름들
GUI에서 그룹 이름을 바꿨다면 YAML의 rules와 반드시 일치시키고, 편집 후에는 프로필 검증과 코어 로그로 기동 오류가 없는지 확인하세요. 구독 링크가 갱신되지 않으면 노드 목록이 비어 있어 해당 정책 그룹이 비정상 동작할 수 있으므로, 무료 클라이언트로도 구독 URL 응답을 먼저 점검하는 습관이 좋습니다.
증상·원인·조치 대조: Perplexity·차단처럼 보일 때
한눈에 훑기 위한 대조표입니다. 동일 증상이라도 네트워크 스택에 따라 다른 경우가 있어, 위에서 아래로 배제하는 용도로 쓰면 됩니다.
- 증상: 질문 버튼 후 바로 네트워크 오류 — 가능 원인: 해당 호스트가 아직 규칙에 없거나 MATCH에 먼저 걸림 — 조치: 로그에서 호스트 확인 후
DOMAIN-SUFFIX추가·순서 상향. - 증상: 긴 응답 중간에 끊김 — 가능 원인: 노드 불안정·읽기 타임아웃·긴 스트림 — 조치: 다른 노드 선택, 클라이언트 타임아웃 상향과 병행.
- 증상: 이미지·카드만 비어 있음 — 가능 원인: 본문과 다른 CDN 접미사가 DIRECT 또는 차단 경로 — 조치: Network에서 실패 URL의 호스트를 추가.
- 증상: 터미널·curl은 되고 브라우저만 실패(또는 그 반대) — 가능 원인: 시스템 프록시 미적용·앱별 프록시·확장 충돌 — 조치: TUN 모드 여부, 브라우저 전용 프로필 정리.
- 증상: 특정 시간대만 불안정 — 가능 원인: 혼잡·국제 회선·DNS 캐시 — 조치: DNS·노드 리전 변경, fake-ip·DNS 글과 병행.
DOMAIN-SUFFIX를 쓰지 않고도 빈틈을 메울 수 있습니다. AI 검색 세션은 호스트 종류가 늘어나기 쉬우니 주기적으로 한 번씩 로그를 스냅샷해 두면 이후 편집이 빨라집니다.
DNS·TUN·fake-ip를 함께 봐야 하는 이유
도메인 기준 규칙은 그 전에 어떤 IP로 해석되느냐에 영향을 받습니다. fake-ip 모드에서는 화면에 보이는 주소와 코어 내부 매칭이 달라 보여 «규칙을 넣었는데 DIRECT로 간다»는 혼란이 생기기도 합니다. 규칙 변경과 같은 날 DNS 스택(enhanced-mode, nameserver, 도메인별 DNS)을 점검하는 것이 좋습니다.
브라우저는 시스템 프록시를 따르지만 터미널·일부 앱은 그렇지 않을 수 있어, «웹만 Perplexity»를 맞추려면 TUN·앱별 예외를 함께 검토하세요. 데스크톱 전반 적용은 Clash TUN·시스템 프록시 가이드와 연결해서 읽으면 흐름이 자연스럽습니다.
다른 생성형 AI 분기 글과 역할 나누기
본 글은 Perplexity·perplexity.ai 축의 DOMAIN-SUFFIX·정책 그룹·규칙 순서에 초점을 맞췄습니다. Grok·xAI, Anthropic, OpenAI 등은 호스트 집합이 전혀 다르므로, 같은 프로필 안에서 블록을 나눠 두면 장애 시 어느 제품 쪽인지 빨리 가릴 수 있습니다. 오케스트레이션·에이전트 워크플로까지 한 번에 묶어야 한다면 LangGraph·n8n Cloud 분기 글과 조합해 보세요.
코어 업그레이드·호환성은 미호모 코어 업그레이드 가이드와 이어 읽을 수 있습니다.
마무리
2026년에도 Perplexity 같은 AI 검색은 UI·질의 API·미디어·공유 링크가 서로 다른 호스트로 갈라지기 쉽습니다. Clash에서는 분기 규칙으로 perplexity.ai 등 필요한 접미사를 명시적으로 묶고, 정책 그룹으로 그 묶음의 아웃바운드를 고정하면 «화면만 열리고 질문만 차단»에 가까운 증상을 줄이기 쉽습니다. 증상이 남으면 규칙만 고집하기보다 DNS·노드·앱별 프록시·구독 링크를 함께 보는 것이 중요합니다.
같은 Clash 계열도 GUI와 프로필 머지 방식은 제품마다 다르지만, 최종적으로 코어가 읽는 YAML 한 장을 기준으로 생각하면 디버깅이 빨라집니다. 반복되는 수동 편집보다 검증된 무료 클라이언트에서 프로필·구독 URL을 한 번 맞춰 두는 편이 장기적으로 편한 경우가 많습니다.