1. 어떤 증상부터 네트워크를 의심할까
perplexity.ai 랜딩은 보이는데 검색 실행 직후 응답 스트림이 끊기거나, 모바일 앱에서만 “네트워크 오류”가 반복되면 개발자 도구·앱 로그에 실패한 호스트 이름이 남습니다. 데스크톱 클라이언트·CI·에이전트가 Perplexity API(예: api.perplexity.ai)를 부를 때는 OpenAI 호환 베이스 URL을 쓰는 경우가 많아, 브라우저 세션과 API 트래픽이 서로 다른 규칙 분류에 매칭되면 “웹은 되는데 스크립트만 실패”처럼 보이기 쉽습니다. 이때 원인이 항상 “노드 품질”만은 아니며, url-test 그룹이 짧은 주기로 출구를 바꿔 관측 IP가 흔들리면 로그인·쿠키·리다이렉트 체인이 어긋나기도 합니다.
서비스 측 이용 제한·지역·결제·조직 정책은 프록시만으로 해결되지 않는 경우가 많습니다. 본문에서는 사용자가 프로필에서 조정할 수 있는 규칙 순서·노드 고정·DNS·브라우저 DoH 충돌 여부를 중심으로 설명합니다. 클라이언트 선택은 Windows용 Clash 비교를, 문법은 설정 가이드와 함께 보면 적용이 빠릅니다.
2. ChatGPT·Gemini·Claude 글을 그대로 가져오면 안 되는 이유
저장소의 ChatGPT·OpenAI 글은 openai.com·chatgpt.com 계열을, Google Gemini 글은 googleapis.com·gemini.google.com 등을, Claude·Anthropic 글은 anthropic.com·claude.ai를 다룹니다. Perplexity는 웹·앱이 perplexity.ai 네임스페이스에 머무는 동안, 공식 문서·개발자 콘솔은 docs.perplexity.ai·console.perplexity.ai 같은 별도 호스트로 갈라지고, Sonar·Search·Agent 계열 API는 api.perplexity.ai를 중심으로 동작합니다. 따라서 다른 브랜드용 규칙만 잘 써 두었다고 해서 Perplexity 트래픽이 자동으로 같은 프록시 그룹에 들어가지 않습니다.
DOMAIN-KEYWORD,perplexity처럼 지나치게 넓은 키워드는 타사 호스트명까지 끌어올 위험이 있어, 가능하면 본인 환경에서 관측한 DOMAIN-SUFFIX 위주로 좁히는 편이 안전합니다. 제품 업데이트마다 하위 도메인·정적 자원 CDN이 늘 수 있으므로, 장애가 날 때마다 네트워크 탭·터미널 로그에 찍힌 정확한 FQDN을 규칙 목록에 덧붙이는 습관이 장기적으로 가장 비용이 적습니다.
3. Perplexity 웹·API·문서가 자주 쓰는 호스트(개념)
브라우저에서 perplexity.ai를 열면 HTML·자바스크립트 번들, 아이콘·폰트, 실시간 스트림(wss 등)이 서로 다른 이름으로 요청될 수 있습니다. 공식 문서에 따르면 Chat Completions·Sonar·Search·Agent 등 API 엔드포인트는 https://api.perplexity.ai를 베이스로 하며, 키 관리·콘솔 워크플로에는 console.perplexity.ai, 문서·레퍼런스에는 docs.perplexity.ai가 등장합니다. 팀에서 문서만 허용하고 API는 다른 방화벽 정책으로 나누는 경우, “문서는 열리는데 SDK만 실패” 같은 정책 분할과 맞물려 디버깅이 꼬이기 쉽습니다.
정적 자원이 글로벌 CDN·서드파티 호스트로 나가면 한 줄짜리 화이트리스트로는 부족합니다. 앱 빌드마다 추적·분석 도메인이 추가될 수도 있으니, 실패 시점의 호스트 목록을 모아 규칙을 확장하는 접근이 맞습니다. 모바일 앱은 OS 수준 DNS·프라이빗 릴레이·다른 VPN과의 상호작용까지 같이 봐야 할 때가 있습니다.
공식 문서와 실제 패킷
문서에 적힌 베이스 URL과 브라우저·러너가 실제로 여는 이름이 항상 같지는 않습니다. 릴리스 노트를 보면서 규칙을 주기적으로 점검하고, 스테이징에서 먼저 매칭 로그를 확인하는 편이 운영 부담을 줄입니다.
4. Clash 규칙 분류로 Perplexity 도메인 묶기
Clash(Mihomo 계열)에서는 RULE 모드에서 위에서 아래로 첫 매칭이 적용됩니다. Perplexity 관련 호스트를 하나의 정책 그룹(예: PPLX-AI)에 모으려면 구체적인 DOMAIN-SUFFIX를 위에 두고, 넓은 규칙은 아래에 두는 순서가 안전합니다. 아래는 이해를 돕기 위한 예시 스켈레톤이며, 실제 제품 변경에 따라 하위 도메인이 달라질 수 있으니 반드시 본인이 캡처한 호스트로 바꾸세요.
rules:
- DOMAIN-SUFFIX,perplexity.ai,PPLX-AI
- MATCH,OthersDOMAIN-SUFFIX,perplexity.ai는 보통 www·api·docs·console 등 해당 접미사 아래 호스트를 함께 묶습니다. 네트워크 탭에 다른 최상위 도메인이 보이면 그때마다 DOMAIN-SUFFIX 또는 DOMAIN 줄을 덧붙이세요. 구독에서 내려받은 대형 규칙 분류 세트를 쓰는 경우, “광고 차단”·“지역 직결” 같은 상위 규칙에 먼저 걸려 아래 줄이 실행되지 않는지 연결 로그로 확인하세요. proxy-groups에 PPLX-AI 이름의 그룹을 실제로 정의해 두어야 하며, 이름이 어긋나 있으면 구문 오류나 의도치 않은 REJECT로 이어질 수 있습니다. rule-providers로 외부 목록을 쓴다면 갱신 주기와 우선순위를 팀 표준에 맞춰 문서화해 두면 온콜 대응이 수월합니다.
5. 노드 선택과 정책 그룹
노드 선택은 ping이 가장 낮은 서버가 항상 정답은 아닙니다. 동일 구독이라도 회선 혼잡·피어링 구간에 따라 TLS 왕복과 패킷 손실이 달라지고, AI 검색 응답처럼 긴 스트리밍에서는 끊김이 체감으로 드러납니다. url-test가 짧은 주기로 최저 지연 노드를 바꾸면 출구 IP가 흔들려 세션 안정성이 떨어질 수 있으니, 증상이 있을 때는 select로 한 노드를 고정하거나 fallback 계열로 바꿔 비교해 보세요.
시스템 프록시만 쓰는 브라우저와 TUN으로 전체 트래픽을 덮는 구성은 증상 패턴이 다릅니다. TUN을 켠 상태에서는 로컬 망 예외·Windows 방화벽·다른 VPN과의 충돌을 함께 봐야 하므로 TUN 문서와 TUN 트러블슈팅 글을 참고하세요. 사내망에서는 분할 터널링 정책과 충돌하지 않는지 보안 팀 가이드도 한 번 짚는 것이 좋습니다.
6. DNS·DoH·fake-ip가 만드는 착시
규칙이 맞아 보여도 DNS 조회가 먼저 실패하면 애플리케이션은 프록시를 타기 전에 끊깁니다. fake-ip 모드에서는 도메인과 가상 IP 매핑 타이밍이 민감해, OS·브라우저 DoH·사내 리졸버가 동시에 개입하면 “간헐적으로만 된다”는 패턴이 나올 수 있습니다. perplexity.ai나 api.perplexity.ai가 의도와 다른 리졸버로 풀리면 엣지까지의 경로가 달라져 지연이 커지기도 합니다.
점검 순서로는 (1) Clash DNS 패널의 리졸버·폴백 설정, (2) 운영체제 캐시, (3) 브라우저 전용 DoH를 차례로 확인합니다. DIRECT로 나가야 할 내부 호스트가 오탐으로 프록시에 탄 경우에도 비슷한 증상이 나오므로, 코어 로그에서 어떤 규칙에 매칭됐는지를 습관적으로 읽는 것이 중요합니다. 터미널 도구가 시스템 프록시를 무시한다면 터미널 프록시·환경 변수 글과 병행해 점검하세요. 입문 시 모드 전환 실험은 튜토리얼과 함께 하면 부담이 적습니다.
7. 적용 후 검증 순서
설정을 저장한 뒤에는 (1) 코어 재시작 또는 프로필 핫 리로드, (2) 브라우저에서 perplexity.ai 강력 새로고침, (3) 터미널에서 프록시 환경 변수를 지정한 curl로 api.perplexity.ai에 대한 TLS 핸드셰이크만 짧게 확인하는 순서가 실무적입니다. GUI 클라이언트는 연결 테스트 기능으로 동일 호스트를 찍어 볼 수 있습니다.
여전히 스피너가 길다면 네트워크 탭에서 실패한 요청의 상태 코드·CORS·WebSocket 종료 사유를 먼저 보고, 그 호스트명을 규칙에 추가합니다. API만 문제일 때는 애플리케이션 로그의 URL 문자열이 곧바로 힌트가 됩니다. 이때도 계정 측 제한 가능성을 열어 두고, 지원팀에 문의할 정보(시간대·요청 ID)를 함께 모아 두면 대응이 빨라집니다.
9. 증상별 자가 점검
아래 표는 Perplexity 사용 환경에서 무엇을 먼저 볼지 정리한 것입니다.
| 증상 | 의심 지점 | 조치 |
|---|---|---|
| 페이지는 뜨는데 검색·스트림만 실패 | WebSocket·SSE·API 하위 호스트 규칙 누락 | 네트워크 탭에서 실패 FQDN 확인 후 규칙 추가 |
| 브라우저는 되는데 SDK·curl만 오류 | api.perplexity.ai가 다른 정책으로 매칭 |
로그의 URL을 기준으로 접미사 규칙 정렬 |
| 간헐적 타임아웃·끊김 | 혼잡한 출구, DNS 흔들림, url-test 전환 | 수동 select·DNS 고정·fallback 실험 |
| 문서·콘솔만 열리고 앱은 실패 | docs·console과 앱 API가 서로 다른 노드·DNS |
관련 호스트를 동일 그룹으로 묶기 |
LAN에서 Mixed Port를 열어 둔 경우 방화벽·포트 설정과 충돌하지 않는지도 함께 확인하세요.
10. 요약
Perplexity 웹·앱과 api.perplexity.ai 기반 API는 서로 다른 호스트가 동시에 움직이기 때문에, 한 줄짜리 시스템 프록시 설정보다 도메인 기준 규칙 분류와 노드 그룹 실험이 체감 안정성을 좌우합니다. 화면이 비거나 계속 로딩만 돌 때도 네트워크 측에서는 경로 일관성·DNS·브라우저 DoH·출구 전환을 먼저 의심해 볼 수 있습니다.
공유된 규칙 세트를 가져왔더라도 본인 프로필에서의 매칭 순서는 직접 확인하는 것이 안전합니다. 연결 기록과 규칙 테스트가 읽기 쉬운 최신 Mihomo 계열 클라이언트를 쓰면 호스트가 늘어나는 SaaS에 맞춰 유지보수하기에도 유리합니다.
설치 패키지는 공식 다운로드 페이지에서 받는 것이 혼선이 적고, 오픈 소스 저장소는 빌드·이슈 확인용으로 참고하면 됩니다.
→ Clash를 무료로 내려받아 Perplexity·perplexity.ai용 규칙 분류와 노드 정책을 직접 맞춰 보세요