2026년 Perplexity가 안 열릴 때 Clash로 맞추기: 도메인 규칙·분류·DNS·실측
AI 검색으로 주목받는 Perplexity는 2026년에도 웹·모바일·브라우저 확장·엔터프라이즈 기능까지 확장되면서, TLS 레벨에서 여러 호스트로 트래픽이 갈라지는 전형적인 구조입니다. 뉴스 사이트는 되는데 perplexity.ai만 비거나, 로그인은 되는데 답변 스트림만 끊기는 식으로 증상이 한쪽에만 몰리면 원인이 전부 「노드 품질」만은 아닐 수 있습니다. 이 글은 본 블로그의 ChatGPT·OpenAI·Google Gemini·Claude·DeepSeek·Grok 튜토리얼과 호스트 집합을 겹치지 않게 유지하면서, Perplexity 전용으로 자주 보이는 도메인 후보·최소 YAML 분류·DNS(fake-ip·DoH)·규칙 우선순위·Rule·Global·TUN을 한 체크리스트로 묶어 안정 접속을 목표로 정리합니다. Perplexity·Clash·분류 규칙·DNS·AI 검색으로 찾아온 분도 바로 따라 할 수 있게 구성했습니다.
① 왜 Perplexity는 「한 줄 DOMAIN-SUFFIX」로 끝내기 어렵나
브라우저에서 질의를 입력하면 HTML·정적 자산·실시간 응답·계정·결제·실험 기능이 서로 다른 서브도메인과 CDN으로 흩어집니다. 모바일 앱이나 데스크톱 래퍼는 OS 수준 DNS 캐시·배터리 최적화와 엮이기도 하고, 브라우저 확장은 권한·스토리지 분리 때문에 데스크톱 앱과 같은 YAML이라도 체감이 달라질 수 있습니다.
그래서 실무에서는 브랜드 이름보다 SNI에 찍히는 실제 호스트를 기준으로 규칙을 쌓는 편이 안전합니다. 서비스는 업데이트될 때마다 호스트가 늘거나 바뀔 수 있으므로, 아래 목록은 출발점이며 확정은 Clash 연결 로그와 개발자 도구의 네트워크 탭으로 맞추는 것이 좋습니다. 규칙 문법이 처음이면 사용자 정의 규칙 튜토리얼에서 rules와 proxy-groups 이름을 맞추는 방법부터 익히면 실수가 줄어듭니다.
② 분류 대상: Perplexity 웹·앱·API에 자주 붙는 도메인 후보
공식 제품 도메인으로 자주 거론되는 것은 perplexity.ai와 www.perplexity.ai입니다. 일부 환경에서는 단축·리다이렉트·내부 API에 pplx.ai 계열 호스트가 로그에 함께 나타나기도 하며, 정적 자산이나 미디어는 CDN 호스트가 추가로 붙는 사례가 있습니다. 엔터프라이즈·팀 기능을 쓰면 조직 단위 호스트가 더해질 수 있으니, 실제로 자신의 계정에서 뜨는 이름을 우선해야 합니다.
- 웹·제품 진입:
perplexity.ai,www.perplexity.ai - 보조·단축·API 계열(환경마다 상이): 로그에 보이는
pplx.ai하위 호스트 - 인증·결제·서드파티: 로그에 따라
stripe.com등 결제 도메인이 섞일 수 있음(필요 시 별도 정책) - 정적·CDN: 제품 업데이트에 따라 달라지므로 로그에서
DOMAIN-SUFFIX로 보강
한 번에 아주 넓은 키워드 규칙을 쓰면 설정은 쉬워지지만, 의도하지 않은 트래픽까지 같은 출구로 흘러 스플릿 라우팅 이점이 줄어듭니다. 처음에는 위 후보처럼 좁은 서픽스부터 넣고, 로그에 새 이름이 뜰 때마다 덧붙이는 방식이 유지보수에 유리합니다. OpenAI·Google 계열과 비교하려면 ChatGPT·OpenAI 분류·Google Gemini 분류 글의 호스트 표를 나란히 두고, 행 순서가 서로 덮어쓰지 않는지도 함께 확인하세요.
③ 최소 규칙 예시: Perplexity 계열만 PROXY, 나머지는 DIRECT
아래는 개념 YAML입니다. PROXY 자리에는 구독 프로필의 프록시 그룹 이름을 넣고, 맨 아래 MATCH는 본인 환경(국내 트래픽 DIRECT 등)에 맞게 조정하세요.
rules:
# Perplexity — add hosts seen in your client logs after updates
- DOMAIN-SUFFIX,perplexity.ai,PROXY
- DOMAIN-SUFFIX,pplx.ai,PROXY
- MATCH,DIRECT
pplx.ai를 넣지 않는 환경도 있으므로, 무조건 복사하기보다 로그에 실제로 보이는지를 먼저 확인하는 편이 안전합니다. 아무 것도 붙지 않을 때는 잠시 MATCH,PROXY로 바꿔 터널·노드 자체가 정상인지부터 가르는 것도 좋은 디버깅 순서입니다. 반대로 국내 사이트까지 느려지면 범위가 과한 것이니, 다시 좁혀 나가면 됩니다.
④ 웹과 API·백그라운드 동기화를 나누고 싶을 때: 프록시 그룹 두 개
지연·안정성 때문에 브라우저 탭과 API·CLI에 서로 다른 출구를 쓰고 싶다면 그룹을 나눠 규칙에서 이름만 바꿉니다. 예시는 구조 이해용이며, 실제 노드 목록은 본인 구독에 맞게 바꿉니다.
proxy-groups:
- name: PPLX_WEB
type: select
proxies: [🚀 자동 선택, DIRECT]
- name: PPLX_API
type: select
proxies: [🚀 자동 선택, DIRECT]
rules:
- DOMAIN-SUFFIX,perplexity.ai,PPLX_WEB
- DOMAIN-SUFFIX,pplx.ai,PPLX_API
- MATCH,DIRECT
이렇게 나누면 「웹만 간헐적으로 실패한다」일 때 PPLX_WEB만 노드를 바꿔 테스트하기 쉽습니다. 다만 그룹이 늘수록 상단의 GEOIP·거대 RULE-SET과의 충돌을 더 자주 점검해야 합니다. 그룹 중첩·이름 짓기는 프록시 그룹(proxy-groups) 가이드와 함께 보면 정리가 수월합니다.
⑤ 규칙 우선순위: 위에서 아래로, 앞줄이 이긴다
Clash의 rules는 일반적으로 먼저 매칭된 한 줄이 최종 정책이 됩니다. 그래서 GEOIP,KR,DIRECT나 구독에 포함된 RULE-SET이 perplexity.ai보다 위에 있으면, 의도와 다르게 DIRECT로 나가 버릴 수 있습니다. 반대로 지나치게 아래에 두면 이미 MATCH에 걸려 끝나기도 합니다.
재현이 어려울 때는 로그의 매칭된 규칙 이름·행 순서를 남겨 두고, 한 번에 한 줄만 위아래로 옮겨 보는 방식이 안전합니다. 다른 생성형 AI용 블록이 같은 파일에 있다면, Perplexity 전용 줄이 실제로 먼저 적중하는지를 숫자로 확인하는 것이 중요합니다.
⑥ DNS가 원인일 때: fake-ip, DoH, 조회 경로 엇갈림
증상이 「느리다」가 아니라 간헐적 이름 실패·한 앱만 이상한 IP라면 DNS를 의심합니다. fake-ip 프로필에서는 애플리케이션이 보는 주소와 실제 outbound 경로가 어긋나 보일 수 있고, OS나 브라우저 DoH가 켜진 채 Clash dns 블록도 동작하면 어느 쪽이 먼저 응답했는지에 따라 결과가 달라집니다.
IPv6 우선 해석 뒤 특정 구간에서만 막히는 경우에는 OS·코어 설정의 IPv4/IPv6 일관성도 함께 봅니다. TUN과 DNS를 같이 쓸 때의 절차는 TUN 모드·DNS 심화 글의 순서를 참고하면 후보를 빠르게 줄일 수 있습니다.
⑦ 모드 선택: Rule, Global, Direct와 시스템 프록시·TUN
Rule 모드는 앞서 정한 rules 순서대로 매칭합니다. 문제를 처음 재현할 때는 Global을 잠깐 켜서 노드 품질부터 가르는 것이 유용합니다. 시스템 프록시는 프록시를 존중하는 앱 위주로 동작하고, TUN은 가상 NIC로 더 많은 트래픽을 끌어와 규칙 적용을 일관되게 만들 수 있습니다. 회사 PC에서는 사내 VPN·보안 에이전트와 충돌할 수 있으니 정책을 먼저 확인해야 합니다.
터미널에서 curl로 특정 호스트를 호출할 때 HTTPS_PROXY를 쓰는지, Clash의 로컬 포트를 직접 지정하는지에 따라 규칙 적용 여부가 달라집니다. 전역 터널과 규칙 기반의 장단은 Clash와 VPN의 차이에서 정리한 대로, 호스트 단위 정책이 필요하면 Clash 쪽이 유리한 경우가 많습니다.
⑧ 실측 절차: 브라우저 중심으로 로그에 맞추기
- 프로필 백업: YAML보내기 또는 클라이언트 백업으로 현재 설정을 저장합니다.
- Rule 모드: 선택된 프록시 그룹이 의도와 같은지, 상위 GEOIP 등이 Perplexity 호스트보다 먼저 먹지 않는지 확인합니다.
- 단일 탭 테스트: 브라우저에서 Perplexity만 연 뒤 Clash 로그에서 매칭된
DOMAIN·정책을 확인하고, 빠진 서픽스를 추가합니다. - DNS 분리: 실패가 규칙인지 해석인지 나누기 위해 OS 도구와 브라우저 네트워크 탭을 병행합니다.
- 모바일: VPN 권한·배터리 제한·앱별 설정이 데스크톱과 달라 동일 YAML이라도 체감이 다를 수 있습니다.
- 회귀 테스트: 규칙을 고친 뒤에는 국내 뱅킹·사내 포털 등 민감 사이트가 의도대로 DIRECT인지도 함께 확인합니다.
처음 클라이언트를 쓴다면 Clash 입문 튜토리얼에서 프로필·모드 개념을 익힌 뒤 이 체크리스트를 적용하면 훨씬 덜 헷갈립니다. 이 순서는 추상적인 속도 자랑이 아니라, 독자가 직접 따라 하며 재현 가능한 검증을 목표로 했습니다.
⑨ 보안·정책·서비스 약관을 함께 기억하기
네트워크 경로를 다루는 방법과 별개로, Perplexity 이용 가능 지역·약관·조직 보안 정책은 사용자가 스스로 확인해야 합니다. 이 글은 합법적 범위에서의 연결 품질·분류를 기술적으로 설명하는 것이며, 특정 규제를 우회하라는 뜻으로 읽혀서는 안 됩니다. 기업 환경에서는 IT 부서의 프록시·DLP 정책을 우선합니다.
⑩ 정리: AI 검색은 「도메인·DNS·모드」를 한 세트로 보라
2026년에도 AI 검색에 대한 관심은 이어지고, Perplexity처럼 제품이 빠르게 진화하는 서비스일수록 호스트가 늘어나기 쉽습니다. 안정적인 체감은 노드 품질만이 아니라 도메인 규칙이 빠짐없이 매칭되는지, DNS가 같은 경로를 보는지, 규칙 표에서의 순서가 의도와 맞는지에 따라 갈립니다. 반복 시나리오에는 규칙 기반 프록시가 같은 정책을 다시 쓰기 쉬워, 매번 손으로 켜고 끄는 전역 VPN보다 검색·업무 패턴에 맞출 때 유리한 경우가 많습니다.
설치와 버전 안내는 릴리스만 쫓기보다 사이트의 다운로드 페이지를 따르는 편이 혼선이 적습니다. 전역 터널보다 관측 가능한 분류에서 Clash가 장기적으로 잘 맞는 경우가 많습니다. → Clash를 무료로 내려받고, Perplexity용 분류 규칙과 DNS를 맞춰 보세요.