왜 Perplexity는 「웹은 되는데 Pro만 안 된다」처럼 보일까

Perplexity 같은 AI 검색 제품은 브라우저 한 탭 안에서도 역할이 나뉩니다. 메인 대화 UI, 검색 결과 카드, 인용·미리보기 에셋, 계정·구독 상태 확인, 때로는 별도 API·스트림 엔드포인트까지 동시에 붙습니다. 사용자가 느끼기에는 하나의 사이트지만, 실제로는 서로 다른 호스트명에 TLS 연결이 열리고, 각 연결은 Clash 규칙에 따라 다른 정책 그룹으로 떨어질 수 있습니다.

이때 흔한 패턴이 부분 성공입니다. 예를 들어 메인 페이지는 국내 직결이나 빠른 노드로 열리지만, Pro 기능·결제·세션 갱신에 쓰이는 호스트만 해외 프록시 쪽으로 빠지거나 반대로 DIRECT에 남아 차단·지연에 걸리는 경우입니다. HTTPS에서는 ClientHello에 실리는 SNI가 인증서·백엔드 라우팅과 맞아야 하므로, 중간에 투명 프록시나 잘못된 스플릿이 끼면 「전체가 막힌 것처럼」 보이기도 합니다. 증상을 네트워크 측에서 분리하려면 연결 로그·규칙 적중 가이드의 흐름으로 호스트별로 무엇이 어디로 갔는지부터 확인하는 것이 빠릅니다.

💡
역할 분담 OpenAI·ChatGPT 경로는 ChatGPT·OpenAI API 가이드, Google 쪽은 Gemini·AI Studio 글에서 다룹니다. 이 문서는 Perplexity 웹·Pro·계정 연동에 초점을 맞춥니다.

접속 면 나누기: 웹 UI, 계정·Pro, API·스트림

설정을 단순하게 유지하려면 최소 세 덩어리로 생각하세요. 첫째, 일반 사용자가 쓰는 웹 대화 UI(검색·답변 스트림). 둘째, 로그인·세션·Pro·결제와 연관된 호스트 묶음. 셋째, 앱·확장·자동화에서 쓰일 수 있는 API·이벤트 스트림 성격의 호스트입니다. 제품 업데이트마다 정확한 서브도메인은 바뀔 수 있으므로, 문서에 적힌 예시는 출발점일 뿐이고 실제 트래픽 로그의 도메인을 근거로 규칙을 보강해야 합니다.

대표적으로 perplexity.ai와 www.perplexity.ai는 대부분의 웹 세션에 등장합니다. 그 밖에 CDN·측정·인증·결제(서드파티) 호스트가 섞이면, 한 줄짜리 MATCH 규칙만으로는 오히려 불안정해질 수 있습니다. 넓은 DOMAIN-SUFFIX를 무분별하게 추가하기보다, 먼저 로그에 반복 등장하는 이름을 리스트업한 뒤 정책 그룹 단위로 묶는 편이 안전합니다.

YAML 예시: Perplexity 전용 정책 그룹과 DOMAIN 규칙

아래는 개념 예시입니다. 프록시 이름·구독 구조는 환경에 맞게 바꾸세요.

proxy-groups:
  - name: PPLX-WEB
    type: select
    proxies:
      - US-PPLX-STABLE
      - JP-PPLX-STABLE
      - DIRECT
  - name: PPLX-ACCOUNT
    type: select
    proxies:
      - US-PPLX-STABLE
      - DIRECT

rules:
  # Place before broad GEOIP / MATCH
  - DOMAIN-SUFFIX,perplexity.ai,PPLX-WEB
  - DOMAIN-SUFFIX,pplx.ai,PPLX-WEB
  # Add log-derived hosts (auth, CDN, API) with care
  # - DOMAIN-SUFFIX,example-cdn.net,PPLX-WEB
  - MATCH,GLOBAL

계정·Pro 전용 호스트를 분리하고 싶다면 PPLX-ACCOUNT 그룹을 두고 로그에서 확인된 호스트만 넣습니다. 한 그룹에 모든 것을 몰아넣어도 되지만, 「웹은 되는데 결제만 실패」처럼 갈라질 때 원인 추적이 어려워집니다. 원격 구독이 규칙을 덮어쓴다면 Clash Meta 오버라이드의 prepend-rules 등으로 로컬 레이어를 얹으세요.

고정 노드: url-test가 세션을 자를 때

AI 응답 스트림은 한 번의 TCP·TLS 연결이 길게 유지되는 경우가 많습니다. 이때 간격이 짧은 url-test나 공격적인 fallback이 응답 중간에 출구를 바꾸면, 브라우저 입장에서는 탭이 멈추거나 Pro 배지만 사라진 것처럼 보입니다. 디버깅 단계에서는 select 그룹에서 검증된 노드 하나에 고정하고 증상이 사라지는지부터 보세요.

고정 노드로 안정화된 뒤에야 자동 선택을 도입하는 것이 순서입니다. 멀티 리전이 필요하면, 동일 리전 고정에서 재현이 멈췄는지 확인한 다음 지역별 그룹을 나눕니다. 연결 로그에서 실패 시각에 노드 이름이 바뀌어 있다면, 지연 문제가 아니라 출구 전환이 원인일 가능성이 큽니다.

규칙 우선순위: GEOIP·국내 직결이 Perplexity를 삼키지 않게

가장 흔한 설정 실수는 GEOIP,CN,DIRECT나 넓은 국내 예외가 앞에 있고, Perplexity용 DOMAIN 행이 뒤에 밀린 경우입니다. DNS 해석 결과에 따라 일부 서브도메인만 국내로 빠지면, 화면은 열리지만 스트림·Pro 검증만 타임아웃되는 형태가 됩니다. 해결책은 구조적입니다. 서비스별 세밀 규칙을 넓은 지역 규칙보다 위에 두세요.

국내 직결과 해외 프록시의 기본 골격은 분류 규칙 최적 전략에서 다룹니다. Perplexity 규칙은 그 위에 얹는 얇은 레이어로 생각하면, 나중에 다른 AI 서비스를 추가할 때도 같은 패턴을 재사용하기 쉽습니다. YAML만 믿지 말고, 실제 적중 정책은 로그로 한 번 더 확인하세요.

DNS·fake-ip·SNI: 이름과 경로 불일치 줄이기

fake-ip 모드에서는 화면에 보이는 호스트와 코어 내부 해석이 어긋나 보일 수 있습니다. 브라우저의 보안 DNS(HTTPS DNS)와 Clash resolver가 동시에 켜져 있으면, 규칙이 기대와 다르게 매칭되기도 합니다. 모드 선택 기준은 fake-ip와 redir-host 비교를 참고하세요.

TLS에서는 SNI가 서버 이름 표시의 중심입니다. 회사망 SSL 검사, 로컬 안티바이러스 HTTPS 스캔, 일부 브라우저 확장이 끼면 SNI·인증서 불일치로 무작위 실패가 납니다. Clash만 남긴 최소 프로필로 재현 여부를 나누면, 프록시가 아닌 상위 계층 문제인지 빠르게 가릅니다.

Pro·계정 증상: 리전·세션·쿠키를 한 노드에 맞추기

유료 플랜·로그인 세션은 지역·IP 일관성에 민감한 편입니다. 짧은 시간에 서로 먼 출구에서 같은 계정을 쓰면 재로그인·플랜 확인 실패가 늘 수 있습니다. 웹 UI와 계정 호스트에 서로 다른 노드를 쓰고 있다면, 우선 동일 리전·동일 노드로 맞춰 증상이 줄어드는지 확인해 보세요.

브라우저 쪽에서는 서드파티 쿠키·스토리지 정책, 확장 프로그램 차단, 엄격한 추적 방지가 로그인 플로우만 깨뜨리는 경우도 있습니다. 네트워크를 고친 뒤에도 Pro만 안 된다면, 시크릿 창·확장 비활성화로 앱 레이어를 분리하는 것이 좋습니다.

TUN·시스템 프록시: 브라우저와 CLI를 같은 길로

브라우저는 OS 프록시나 TUN 모드를 따르지만, 터미널 도구는 HTTPS_PROXY를 별도로 줘야 하는 경우가 많습니다. Perplexity 연동 스크립트나 로컬 봇을 돌린다면 루프백 주소와 mixed-port가 일치하는지 함께 확인하세요.

한 가지 원칙은, 증상이 났을 때 「느린가, 아니면 잘못된 정책으로 DIRECT에 떨어지는가」를 로그의 규칙 적중으로 먼저 가르는 것입니다. 긴 스트림이 끊기면 노드 품질 전에 호스트 누락·순서 역전을 의심하는 편이 빠릅니다.

⚠️
법령·약관 준수 적용 법규, 네트워크 정책, Perplexity 이용약관을 준수하세요. 이 글은 합법적으로 접근 권한이 있는 환경에서 트래픽 경로를 의도대로 맞추기 위한 기술 참고 자료입니다.

증상별 빠른 체크리스트

메인 웹은 열리는데 검색 응답만 끊길 때

스트림·API 후보 호스트가 로그에 찍히는지 보고, 해당 호스트가 PPLX-WEB(또는 동등 그룹)에 명중하는지 확인하세요. 넓은 규칙에 먼저 잡히지 않는지도 함께 봅니다.

Pro·결제·플랜 표시만 실패할 때

계정·결제 관련 호스트를 별도 그룹으로 분리했는지, 그 그룹이 의도한 노드로 가는지 확인합니다. 노드를 단일 값으로 고정해 재현성을 먼저 없애 보세요.

간헐적 TLS·빈 화면만 뜰 때

SNI·인증서 오류 메시지가 로그에 있는지, 기업망·확장·보안 스캔이 개입하지 않는지 점검합니다. DNS 이중화가 의심되면 resolver 설정을 단순화해 재시도합니다.

요약: DOMAIN으로 묶고, 노드를 고정하고, 순서를 지킨다

2026년에도 AI 검색 트래픽은 한 제품 안에서 여러 호스트로 갈라지고, Clash에서는 그 갈라짐이 규칙 순서·정책 그룹·노드 고정 여부로 그대로 드러납니다. Perplexity 웹·Pro가 동시에 안정적으로 쓰이게 하려면 로그 기반으로 호스트를 모으고, 넓은 GEOIP보다 위에 두며, 세션 중 노드가 바뀌지 않게 고정 노드 기준선을 확보한 뒤 자동화를 얹으세요.

클라이언트 설치와 구독 연결이 처음이라면 다운로드 페이지에서 빌드를 받고 구독 URL 가이드로 기본 분류를 만든 뒤, 이 글의 Perplexity 레이어를 추가하면 흐름이 끊기지 않습니다. → Clash를 무료로 내려받아 Perplexity 웹·Pro 트래픽을 의도한 경로로 안정적으로 보내 보세요