1 Perplexity만 따로 규칙을 두는 이유
2026년에도 해외 AI 검색·채팅 서비스는 브랜드마다 호스트 설계가 다릅니다. OpenAI 계열은 ChatGPT 글의 openai.com·chatgpt.com 묶음이 중심이고, Anthropic은 Claude 글의 anthropic.com, Google 계열은 Gemini 글의 googleapis.com 등이 넓게 퍼집니다. DeepSeek는 deepseek.com 축으로 정리할 수 있지만, Perplexity는 브랜드 사이트·앱 백엔드·공식 API가 perplexity.ai 아래에서도 서브도메인별로 역할이 나뉘고, 로그에 pplx.ai 등 짧은 도메인이 함께 보이는 경우가 있습니다. «해외 AI 한 줄»이나 거대 GEOSITE 한 덩어리만 믿으면 웹은 프록시를 타고 앱만 직접 연결되거나, 반대로 API만 다른 출구로 나가 세션·스트리밍이 엇갈리는 증상이 납니다.
Clash에서는 DOMAIN-SUFFIX와 Rule Provider로 호스트 묶음을 명시하고, 지연과 안정성에 맞춰 둔 프록시 그룹 이름을 규칙에서 참조합니다. 목표는 속도 자랑이 아니라 연결 로그에 찍힌 호스트마다 기대한 정책이 걸리게 해서, 데스크톱 브라우저·스마트폰 앱·터미널의 API 스크립트가 같은 노드 정책을 쓰게 만드는 것입니다. 클라이언트가 없다면 다운로드 페이지에서 Mihomo를 지원하는 GUI를 고른 뒤, 아래 YAML 조각을 기존 프로파일에 합치면 됩니다.
2 웹 브라우저·모바일 앱·API: 세 갈래를 동시에 맞추기
웹: 사용자는 주로 perplexity.ai와 채팅 UI로 들어갑니다. 정적 자원·분석·인증 리다이렉트는 추가 서브도메인이나 CDN으로 갈 수 있어, API만 프록시에 넣고 프런트 자원을 빼면 «응답은 되는데 화면만 반쯤» 같은 증상이 납니다. 스트리밍 답변이 중간에 끊기면 HTTP/2·회선 품질과 함께 호스트별 출구 불일치도 의심할 만합니다.
모바일 앱: iOS·Android 앱은 시스템 프록시를 따르지 않는 경우가 많아, Wi-Fi에서 브라우저만 되고 앱만 실패하는 패턴이 흔합니다. 이때는 TUN 모드로 기기 전체 트래픽을 규칙 엔진에 넣는 편이 단순합니다. Android에서는 FlClash 설정 글과 맞추고, VPN 슬롯·배터리 최적화 예외를 함께 점검하세요. iOS에서는 Stash 등 구독 가져오기 문맥의 클라이언트로 TUN 또는 동등한 전역 터널을 켜는지 확인합니다.
API: 개발자·자동화 스크립트는 보통 https://api.perplexity.ai 베이스를 쓰고, 공식 문서는 docs.perplexity.ai 등 별도 호스트에 있습니다. Python·Node SDK와 curl은 시스템 프록시를 무시하는 경우가 많아, 브라우저만 정상이고 터미널만 타임아웃하는 패턴이 자주 나옵니다. HTTPS_PROXY를 Clash 리스닝 주소에 맞추거나 TUN으로 통일하세요.
perplexity.ai 접미사로 한 축을 잡되, 로그에 새 호스트가 뜨면 Rule Provider나 DOMAIN-SUFFIX 줄을 보강하는 식으로 유지보수하세요.
3 도메인 묶음·DOMAIN-SUFFIX·규칙 순서
최소한 DOMAIN-SUFFIX,perplexity.ai로 브랜드 축을 잡는 것을 권장합니다. 이렇게 하면 www.perplexity.ai·api.perplexity.ai·docs.perplexity.ai 등이 같은 규칙 줄에 포함되는 경우가 많습니다. 연결 로그에 pplx.ai 등 다른 루트 도메인이 보이면 한 줄 추가하거나, 신뢰할 수 있는 원격 Rule Provider 목록에 합치고 interval로 갱신하세요.
규칙 순서는 실수하기 쉽습니다. 너무 넓은 MATCH나 «해외 전체» 규칙이 위에 있으면 Perplexity 전용 줄이 도달하기 전에 흡수되거나, 반대로 직접 연결이 먼저면 TLS 단계에서 끊길 수 있습니다. Perplexity 묶음은 구독이 준 «큰 덩어리»보다 앞쪽에 두고, 디버깅 시 Connections 로그에서 perplexity·pplx로 필터해 기대한 PROXY_PERPLEXITY 같은 그룹 이름이 찍히는지 확인하세요.
DNS·FakeIP 설계는 DNS 유출 방지 가이드와 맞추는 것이 안전합니다. SNI와 정책이 어긋나면 «가끔만 인증서 오류»처럼 보이기도 합니다.
4 Rule Provider와 rules: 예시
아래는 개념 예시입니다. proxy-groups 이름·노드 목록은 본인 프로파일과 맞추고, rule-providers의 url은 실제로 신뢰하는 목록으로 바꾸세요. 원격 목록이 없으면 RULE-SET 줄을 빼고 DOMAIN-SUFFIX,perplexity.ai와 필요 시 DOMAIN-SUFFIX,pplx.ai만 써도 됩니다.
# Example only — merge with your full profile
proxy-groups:
- name: PROXY_PERPLEXITY
type: select
proxies:
- AUTO-BEST
- DIRECT
rule-providers:
perplexity:
type: http
behavior: classical
url: "https://example.com/rules/perplexity.txt"
path: ./ruleset/perplexity.yaml
interval: 86400
rules:
- RULE-SET,perplexity,PROXY_PERPLEXITY
- DOMAIN-SUFFIX,perplexity.ai,PROXY_PERPLEXITY
- DOMAIN-SUFFIX,pplx.ai,PROXY_PERPLEXITYDOMAIN-KEYWORD,perplexity는 다른 사이트·로그 문자열과 겹칠 수 있습니다. 접미사·규칙 집합을 우선하고 KEYWORD는 임시 진단용으로만 쓰세요.
5 모바일 앱에서의 TUN·분할 터널
앱이 시스템 VPN/TUN 슬롯을 쓰지 않으면 DNS조차 기대한 resolver로 가지 않을 수 있습니다. «브라우저 Perplexity만 되고 앱만 안 된다»면 Wi-Fi의 HTTP 프록시 설정만으로는 부족한 경우가 많고, Clash 측 TUN 또는 모바일 클라이언트의 동등한 전역 라우팅을 켜야 합니다. 분할 터널(앱별 예외)을 쓰는 경우 Perplexity 앱이 예외 목록에서 빠지지 않았는지 확인하세요. 예외에 넣으면 다시 직접 연결로 나가 규칙이 적용되지 않습니다.
Cursor·Clash 글은 IDE·확장 마켓 쪽 호스트에 초점이 있고, 본문은 OS·앱 레벨에서 Perplexity 호스트가 한 그룹으로 가게 만드는 데 초점을 둡니다. 둘 다 쓰면 규칙을 단순히 합치기보다 로그로 각각 검증하는 편이 안전합니다.
6 GEOSITE 한 덩어리에만 기대지 않기
구독에 들어 있는 GEOSITE·거대 «비중국» 묶음은 편하지만 해상도가 거칠고 갱신도 커뮤니티 속도에 묶입니다. AI 서비스 트래픽만 낮은 지연 노드로 보내고 싶은데 무관한 사이트까지 같은 출구를 타게 되거나, 새 CDN 호스트가 목록에 없으면 직접 연결로 새었다가 끊기는 일이 생깁니다. 범용 규칙 위에 Perplexity 전용 RULE-SET 또는 DOMAIN-SUFFIX 줄을 덧씌우는 편이 팀에서도 설명하기 쉽습니다.
7 API·문서·빌링 콘솔
공식 SDK나 REST 클라이언트가 최종적으로 api.perplexity.ai를 부르면 네트워크 레이어에서는 브라우저·앱과 같은 프록시 그룹을 타야 합니다. 앱이 시스템 프록시를 지원하면 Clash와 동기화하고, 아니면 TUN이 더 단순합니다. 키 발급·사용량·과금을 위해 웹 콘솔(perplexity.ai 내 설정·빌링 경로, 서비스 업데이트에 따라 URL이 달라질 수 있음)에 브라우저로 접속할 때도 동일 정책이 걸리게 두는 것이 로그 분석에 유리합니다. 문서 사이트는 읽기 전용이어도 차단되면 삽입된 예제·리다이렉트가 깨질 수 있으니, 필요하면 같은 그룹에 포함하세요.
출처 불명의 공용 프록시에 API 키를 태우지 마세요. 회사망에서는 보안 정책에 따라 프록시 사용 자체가 제한될 수 있습니다.
8 API 키·쿼터·준수
연결이 되어도 401·403·429·쿼터 초과·결제 오류는 계정·프로젝트 설정 문제일 수 있습니다. 키는 저장소에 올리지 말고 비밀 저장소·최소 권한으로 관리하세요. 본문은 클라이언트 측 경로 가용성만 다루며 지역 법규·고용 계약·서비스 약관 해석을 대신하지 않습니다.
9 DNS·로그·자주 보는 오류
«해석은 되는데 연결이 안 된다»면 DNS 단계와 TCP·TLS 단계를 나누어 보세요. FakeIP·DoH·fallback이 꼬이면 규칙은 맞는데 세션이 다른 출구로 나가기도 합니다. 노드를 바꿀 때마다 같은 호스트가 들쭉날쭉하면 선로 품질을 의심하고, 노드를 고정한 채 로그의 호스트 목록을 한 번에 모아 보는 편이 빠릅니다.
스트리밍 응답이 중간에 끊기면 HTTP/2와 불안정한 회선 조합도 흔한 원인입니다. 브라우저에서 채팅까지 확인 → 최소 스크립트로 API 헬스 체크 → 모바일 앱에서 동일 계정으로 재현 순서를 권장합니다.
- 브라우저만 되고 앱만 실패: TUN 미적용·분할 터널 예외·배터리 최적화를 의심합니다.
- 웹·앱은 되는데 API만 403/401: 규칙보다 키·지역·계정 상태를 먼저 확인합니다.
- 간헐적 TLS 오류: DNS·SNI·중간 프록시 충돌 가능성을 점검합니다.
10 자주 묻는 질문
- ChatGPT 규칙만 있으면 되나요? OpenAI 도메인과 Perplexity 도메인은 다릅니다. 본문의
perplexity.ai묶음을 추가하세요. - API만 좁히고 싶다: 가능은 하지만 웹·앱·문서 호스트를 빼면 다시 로그로 검증해야 합니다.
- Gemini·Claude·DeepSeek 규칙과 충돌? 순서와 프록시 그룹만 분리하면 병행 가능합니다. 대상 도메인이 다릅니다.
- Windows 스토어 앱에서만 이상하다: Windows UWP·Loopback 글을 참고해 예외를 점검하세요.
11 정리
2026년에도 Perplexity를 웹·모바일 앱·API에서 안정적으로 쓰려면 «전역 스위치 하나»보다 호스트 묶음을 유지보수 가능하게 두는 편이 낫습니다. Clash에서 DOMAIN-SUFFIX·Rule Provider로 perplexity.ai 축을 전용 프록시 그룹에 묶고, 필요 시 pplx.ai를 덧붙이며, 브라우저·앱·터미널을 TUN 또는 환경 변수로 맞추면 로그 기반 디버깅이 쉬워집니다. 규칙 가독성과 클라이언트 선택 폭에서 다른 도구들보다 실무에 잘 맞는 경우가 많습니다.
설치 패키지는 공식 다운로드 페이지를 우선하세요. 소스·이슈는 GitHub 등을 참고하되, 배포물은 사이트 경로를 쓰는 편이 버전 관리에 유리합니다.
