Perplexity가 안 열리거나 답변이 끊길 때: Clash(mihomo)로 통합형 AI 검색 도메인·DNS·Fake-IP를 맞추는 실측 (2026)

1. 왜 Perplexity만 가끔 불안정해 보일까

Perplexity는 질의 한 번에 메인 앱 호스트, 짧은 링크·추적용 도메인, 정적 자원·API 서브도메인이 한 화면에서 동시에 움직입니다. 그중 일부만 DIRECT나 다른 정책 그룹으로 새면, UI는 반쯤 뜨고 스트리밍 응답만 끊기거나 인용 카드가 비어 있는 것처럼 보일 수 있습니다. 이는 반드시 서비스 장애만 의미하지 않고, Clash 분할에서 경로가 갈라진 경우가 흔합니다.

mihomo에서 Fake-IP를 쓰면 도메인 기반 규칙과 잘 맞지만, 운영체제나 브라우저의 DNS over HTTPS가 우선하면 해석이 엔진 밖으로 나가 규칙과 실제 연결이 어긋납니다. 특히 인용·미리보기용 요청이 별도 호스트로 갈 때 증상이 「가끔만」 나타나기 쉽습니다. OpenAI 계정 제한 같은 서사와 헷갈리지 말고, 먼저 로그에 찍힌 호스트와 아웃바운드를 확정하는 편이 빠릅니다.

2. 단일 LLM 글과 다른, 통합 검색형 AI의 특징

ChatGPT 글은 OpenAI 세션·노드 고정에, Claude 글은 Anthropic 지역 메시지와 DNS 조합에, DeepSeek 글은 국산 API 베이스에 초점이 있습니다. 본문은 그 연장이 아니라 검색·인용·요약이 한 제품 경험으로 묶인 축을 다룹니다. 따라서 YAML을 복사할 때 다른 AI 글의 도메인 목록과 섞지 않는 것이 중요합니다.

Gemini 글은 Google 생태계 호스트와 HTTP/3(QUIC) 점검을 깊게 다룹니다. Perplexity 쪽은 브라우저·앱마다 스택이 달라 전송 계층 이슈가 얼마든지 생길 수 있지만, 2026 기준으로는 독자에게 중복 설명을 피하기 위해 본문에서는 도메인·DNS·정책 그룹 위주로 서술하고, 브라우저 전역 설정은 Gemini 글의 흐름을 참고하도록 안내합니다.

3. 규칙에 넣기 좋은 도메인·서브호스트 출발점

아래는 출발점입니다. 실제 서비스는 CDN·실험 호스트를 추가하거나 바꿀 수 있으므로, 개발자 도구의 네트워크 탭·Clash 로그·앱 디버그 출력에 찍힌 이름을 기준으로 목록을 보강하세요. 운영 단순화를 위해 DOMAIN-SUFFIX,perplexity.ai와 DOMAIN-SUFFIX,pplx.ai로 하위 대부분을 한 번에 잡는 방식이 일반적입니다.

DOMAIN-KEYWORD,plex처럼 과도하게 짧은 키워드는 다른 서비스까지 잡을 수 있어 비추천입니다. 반복되는 접미는 DOMAIN-SUFFIX로 쌓고, 예외만 DOMAIN으로 빼는 패턴이 안전합니다. 클라우드프론트 등 제3자 호스트가 보이면 해당 호스트가 여러 사이트에 공유되는지 확인한 뒤 규칙을 추가하세요.

4. mihomo rules 스니펫

전용 정책 그룹 이름을 예시로 🔷 Perplexity라고 하면, rules에서 넓은 MATCH·지역 규칙보다 위쪽에 둡니다. 그룹·노드 이름은 본인 구독에 맞게 바꿉니다. 우선순위 개념은 고급 라우팅 가이드와 함께 보면 이해가 빨라집니다.

rules:
  # Perplexity / aggregated AI search — above broad MATCH / GEOIP
  - DOMAIN-SUFFIX,perplexity.ai,🔷 Perplexity
  - DOMAIN-SUFFIX,pplx.ai,🔷 Perplexity
  # Add hosts from DevTools / app logs if your client uses extra FQDNs

  # ... LAN, CN, then MATCH
  - GEOIP,PRIVATE,DIRECT
  - MATCH,🔰 Proxy

구독 갱신 시 커스텀 규칙이 덮어써지지 않게 하려면 구독 가져오기와 프로필 머지 순서를 확인하세요. 기업망에서는 SNI·DPI로 특정 경로만 불안정한 경우도 있어, 같은 그룹이라도 노드 지역을 바꿔 대조 실험하는 것이 좋습니다.

5. 웹·앱·확장과 출구 일치

브라우저 탭에서 쓰는 Perplexity와 데스크톱·모바일 앱은 User-Agent뿐 아니라 내부적으로 치는 호스트 집합이 다를 수 있습니다. 한쪽만 전용 그룹에 묶이면 「웹은 되는데 앱만 로그인 실패」 같은 패턴이 납니다. 앱별로 프록시를 켜고 끄는 OS 설정이 있으면 Clash TUN·시스템 프록시와 겹쳐 이중으로 동작하기도 하니, 한 환경에서는 한 가지 출구 스택을 유지하는 편이 디버깅에 유리합니다.

터미널·스크립트에서 API나 비공개 엔드포인트를 호출할 때는 HTTP_PROXY·HTTPS_PROXY가 Clash의 시스템 프록시와 충돌하지 않는지 확인하세요. 컨테이너 환경은 Docker·호스트 Clash 글의 NO_PROXY 정리를 참고하면 실수가 줄어듭니다. IDE·코딩 도구는 Cursor 글에서 말한 것처럼 Electron 트래픽 로그를 먼저 확정하는 루프가 안전합니다.

정책 그룹에 url-test·fallback을 강하게 걸어 두면 스트리밍 응답 중 노드가 바뀌며 세션이 끊겨 보일 수 있습니다. Perplexity처럼 긴 응답을 스트리밍하는 제품은 실측 시 한동안 노드를 고정해 보는 것도 유효한 대조 실험입니다.

6. DNS·fake-ip·nameserver-policy

mihomo에서 enhanced-mode: fake-ip를 쓰면 도메인 규칙과 궁합이 좋지만, 브라우저·OS의 DoH가 우선하면 해석이 Clash 밖으로 새어 규칙과 실제 경로가 어긋날 수 있습니다. 특정 접미만 지정 리졸버로 보내고 싶다면 nameserver-policy를 검토합니다. 아래는 예시이며 실제 업스트림은 본인 정책에 맞게 교체하세요.

# Optional — example only; use your own resolvers
dns:
  nameserver-policy:
    "+.perplexity.ai":
      - https://dns.google/dns-query
    "+.pplx.ai":
      - https://dns.google/dns-query

전체 그림은 Clash 개요에서 DNS와 모드를 함께 보는 것이 좋습니다. 서비스 약관·접속 정책은 사용자마다 다르므로 본문은 전송 경로만 다룹니다. 합법적으로 이용 가능한 환경에서 연결을 안정화하는 용도로만 활용하세요.

7. 실측 점검 순서

권장 순서는 다음과 같습니다. 첫째, Clash 로그에서 문제 요청이 의도한 DOMAIN-SUFFIX 줄에 매칭됐는지 확인합니다. 둘째, 🔷 Perplexity에 묶인 노드의 지연·출구 지역이 기대와 맞는지 Proxies 화면에서 봅니다. 셋째, 웹과 네이티브 앱을 같은 노드로 맞췄을 때 증상이 사라지는지 비교합니다. 넷째, DoH·다른 VPN·TUN 충돌을 점검합니다.

모바일에서는 셀룰러 DNS나 「개인 DNS」 옵션이 mihomo와 겹칠 수 있습니다. Wi-Fi와 LTE를 오가며 증상이 달라지면 단말 쪽 해석 경로를 의심하세요.