1. 증상부터 나누기: “느림”과 “불완전 로딩”
사용자 입장에서는 모두 “Perplexity가 느리다”로 느껴지지만, 관찰 포인트는 다릅니다. 첫째, 모든 요청이 같은 노드로 나가는데도 지연이 큰 경우입니다. 둘째, 일부 호스트만 직결·차단·다른 정책 그룹에 걸려 스트리밍 응답이 중간에 멈춘 것처럼 보이는 경우입니다. 후자는 Clash 연결 패널에 찍히는 도메인 문자열과 브라우저 개발자 도구 네트워크 탭의 호스트 목록을 나란히 놓으면 금방 갈라집니다.
구독 YAML 을 아직 익숙하게 다루지 않는다면 구독 가져오기 튜토리얼에서 프로필을 먼저 안정화한 뒤 이 글의 분류 단계로 넘어오는 편이 좋습니다.
2. 권장 점검 순서
- Clash 가 켜져 있는지, 시스템 프록시인지 TUN 인지 기록합니다.
- 실시간 연결 목록에서 perplexity·pplx 등 관련 호스트가 기대한 정책 그룹으로 나가는지,
DIRECT로 새는지 확인합니다. fake-ip사용 여부를 확인하고, 해석이 흔들리는 접미사에nameserver-policy등을 두는지 봅니다.- 개발자 도구로 수집한 호스트를
DOMAIN-SUFFIX·DOMAIN규칙으로 올리고, 공급자 규칙·로컬 규칙의 순서 충돌을 정리합니다. - 규칙이 맞다는 전제에서 스트리밍·검색 API 에 지터가 적은 노드를 고르고, 과도한 자동 페일오버를 줄입니다.
3. 시스템 프록시와 TUN: 앱마다 다른 출구
macOS·Windows 가 제공하는 시스템 프록시는 대부분의 데스크톱 브라우저에는 잘 전달되지만, 샌드박스형 앱·별도 런타임·일부 Electron 래퍼는 무시하는 경우가 있습니다. 그 결과 같은 PC 에서도 “웹 Perplexity 는 되는데 데스크톱 클라이언트만 이상하다”는 식으로 갈라질 수 있습니다.
TUN 은 라우팅 계층에서 잡아 주므로 이런 불일치가 줄어듭니다. 다만 다른 VPN 과 동시 사용 시 어댑터 충돌이 생기기도 하므로, TUN 모드 안내를 따라 켠 뒤 연결 로그로 Perplexity 관련 트래픽이 모두 Clash 를 통과하는지 다시 확인하세요.
4. DNS·fake-ip: 스피너를 키우는 작은 어긋남
fake-ip 는 체감 지연을 줄이는 데 도움이 될 수 있지만, 해석 결과와 실제 연결 목적지가 어긋나면 TLS 핸드셰이크가 반복되고 SPA 는 끝없이 로딩처럼 보입니다. 특히 CDN 이 끼어 있는 서비스에서 서브도메인마다 다른 엣지로 붙는 패턴이면 증상이 두드러집니다.
상위 DNS 가 신뢰 가능하고 Clash 에서 도달 가능한지 먼저 확인한 뒤, perplexity.ai·pplx.ai 등 핵심 접미사에 별도 해석 정책을 두는 방식을 검토하세요. 필드 이름은 Mihomo 버전에 따라 다를 수 있으니 최신 문서와 예제를 함께 보는 것이 안전합니다.
5. 도메인 수집: 개발자 도구가 최우선 증거
인터넷에 떠도는 “완성된 Perplexity 도메인 목록”은 배포 시점과 지역·A/B 테스트에 따라 빠르게 달라질 수 있습니다. 그래서 이 글은 고정 목록을 외우게 하기보다, 본인 세션에서 실제로 붙는 호스트를 모으는 절차를 권장합니다.
브라우저에서 Perplexity 를 연 뒤 개발자 도구의 네트워크 탭을 켜고, 페이지를 새로고침하거나 질문을 한 번 보냅니다. perplexity.ai 외에 *.cloudfront.net·*.fastly.net 같은 CDN 호스트명, 혹은 전용 서브도메인이 보이면 각각 메모합니다. 실패한 요청(빨간 줄)의 호스트를 우선적으로 Clash 규칙에 올리면 체감이 가장 큽니다.
모바일 앱이나 PWA 를 쓰는 경우에는 동일 Wi-Fi 에 데스크톱 Clash 를 켠 채 로그만 필터링해 보거나, 라우터 단에서 DNS 쿼리 로그를 참고하는 방법도 있습니다. 다만 개인정보·보안 정책에 맞는 범위에서만 수집하세요.
6. 규칙에 올리기 전 체크리스트
아래 표는 사고를 돕는 틀일 뿐이며, 실제 이름과 개수는 반드시 개발자 도구·연결 로그로 검증해야 합니다.
| 구분 | 예시 방향 | 메모 |
|---|---|---|
| 메인 UI | perplexity.ai | 인증·라우팅이 같이 묶이는지 확인합니다. |
| 보조 호스트 | pplx.ai 등 | 짧은 링크·자산 호스트가 따로 보이면 별도 규칙을 고려합니다. |
| CDN | 세션에서 관측된 접미사 | 공급자의 광범위 DIRECT 규칙과 순서가 충돌하지 않게 둡니다. |
| API·스트림 | 네트워크 탭의 XHR·fetch | 스트리밍 응답은 지터에 민감하므로 노드 품질과 함께 봅니다. |
7. 규칙 예시 (정책 그룹 이름은 교체)
# Example only — replace PROXY with your policy group name
rules:
- DOMAIN-SUFFIX,perplexity.ai,PROXY
- DOMAIN-SUFFIX,pplx.ai,PROXY
- DOMAIN-KEYWORD,perplexity,PROXY개발자 도구에서 추가로 본 CDN 호스트는 DOMAIN-SUFFIX,cdn.example.net,PROXY 처럼 하나씩 명시하는 편이 안전합니다. DOMAIN-KEYWORD 는 범위가 넓어질 수 있으니 과도하게 쓰지 말고, 로그에 근거해 좁히세요.
웹 UI 와 API 를 의도적으로 나누고 싶다면 DOMAIN,api.example.com,PROXY_API 식으로 그룹을 분리해 두면 이후 디버깅이 쉬워집니다. Perplexity 의 내부 호스트 명은 시기에 따라 바뀔 수 있으므로, 위 예시는 출발점으로만 두고 본인 세션 기준으로 덮어쓰는 것이 좋습니다.
8. 노드 전략: 순간 속도보다 지터와 안정성
벤치마크 상위 노드라도 짧은 구간에서 패킷 지터가 크면 HTTP/2·스트리밍 응답이 자주 끊깁니다. AI 검색 체감은 “첫 토큰까지의 시간”과 “중간 끊김 없이 이어지는지”가 같이 작동하므로, 규칙이 맞는지 확인한 뒤에는 손실이 적은 회선을 고정하거나 자동 전환 임계값을 완화하는 편이 낫습니다. 전송 계층 특성은 프로토콜 비교 글을 참고해 보조 근거를 얻을 수 있습니다.
9. GUI 워크플로: Clash Verge Rev
연결 패널에서 호스트 문자열을 필터링하면 잘못된 DIRECT 를 빠르게 찾을 수 있습니다. 첫 설치와 구독 흐름은 Clash Verge Rev 초보자 가이드를 따르세요. 규칙 편집 후에는 DNS 캐시를 비우거나 브라우저를 완전히 다시 시작해 이전 연결 상태가 남지 않게 하는 것도 도움이 됩니다.
10. 추가 함정: 확장 프로그램·이중 VPN·구형 규칙
브라우저 확장이 자체 프록시를 켜 두면 OS 설정과 겹쳐 혼란이 커집니다. 점검 시에는 잠시 끄세요. Clash 외 다른 상시 VPN 과 동시에 켜면 루프나 이중 터널처럼 보이는 증상이 납니다. 한 번에 하나의 출구만 남기고 다시 테스트하는 것이 원칙입니다.
공항 구독이 업데이트되며 예전에 넣어 둔 로컬 규칙이 뒤로 밀리거나, 공급자 쪽 광범위 GEOIP,CN,DIRECT 가 의도치 않게 CDN 대역을 직결로 보내는 경우도 있습니다. 규칙 파일 상단에 “Perplexity 전용 블록”을 두고 주기적으로 순서를 재확인하면 재발을 줄일 수 있습니다.
11. 다른 생성형 AI 글과의 관계
ChatGPT·OpenAI 쪽은 전용 글에서 호스트 축을 다룹니다. DeepSeek·Cursor·Copilot 역시 각각 다른 로그인·마켓·Microsoft CDN 문제를 다루므로, 이 글은 Perplexity 프록시와 대화형 검색 UI·CDN 분리에 초점을 맞춘 보조 노트로 쓰시면 중복을 피할 수 있습니다.
12. 정리: 로그 근거를 한 층씩 쌓기
Perplexity 가 검색창에서만 스피너를 도는 현상은 단일 스위치가 아니라 프록시 모드·DNS·규칙 순서·노드 품질이 겹친 결과인 경우가 많습니다. 이 글의 순서대로 연결 로그와 네트워크 탭 증거를 남기면 불필요한 노드 순환과 잘못된 DIRECT 를 빠르게 줄일 수 있습니다.
규칙을 손으로만 다듬기보다 Mihomo 를 내장한 공식 클라이언트에서 로그·업데이트·프로필 전환을 한곳에 모으는 편이 운영에는 더 편할 때가 많습니다. 비슷한 범용 프록시 도구와 비교해도, 구독·분류·연결 기록이 함께 있으면 “일부 자산만 안 받아진다”는 증상을 빠르게 좁힐 수 있습니다. → Clash 를 무료로 내려받고 Perplexity 세션을 같은 출구로 묶어 보세요