Perplexity만 Clash에서 시간 초과되는 이유

Perplexity 웹페이지가 Clash 환경에서 열리지 않거나 검색 결과가 끝없이 로딩된다면, 단순히 “노드가 느리다”라고 판단하기 쉽습니다. 하지만 실제 원인은 브라우저가 접속하는 웹 호스트, 검색 요청을 처리하는 API, 로그인·인증에 필요한 도메인, 정적 파일을 전달하는 CDN이 서로 다른 규칙을 타는 데서 시작되는 경우가 많습니다. 메인 화면은 열리는데 질문을 보낸 뒤 멈추거나, 검색 결과 일부만 표시되고 timeout이 발생한다면 연결 경로가 한 단계에서 끊겼을 가능성이 큽니다.

특히 Clash의 Rule 모드에서 Perplexity 관련 도메인이 규칙에 매칭되지 않으면 마지막의 FINAL 정책으로 흘러갑니다. 이때 브라우저는 시스템 프록시를 사용하지만 DNS 요청은 로컬 네트워크로 나가거나, 반대로 API 연결만 다른 노드로 전달될 수 있습니다. 화면 로딩, 로그인, 질문 전송, 스트리밍 응답이 각각 다른 연결을 만들기 때문에 사용자는 하나의 Perplexity 장애처럼 느끼지만 Clash 로그에는 여러 정책과 여러 호스트가 나타납니다.

첫 점검에서는 노드를 무작정 교체하지 말고 실패 시각을 기록하세요. Perplexity 탭을 새로 연 시간, 질문을 전송한 시간, 오류가 표시된 시간을 기준으로 연결 로그를 필터링하면 어떤 호스트가 마지막으로 응답하지 않았는지 찾기 쉽습니다. 브라우저 개발자 도구를 사용할 수 있다면 Network 탭에서 오래 Pending 상태로 남은 요청의 호스트 이름도 함께 확인합니다. 주소가 매번 바뀔 수 있으므로 특정 도메인 목록을 맹신하기보다 현재 로그에 실제로 찍힌 이름을 기준으로 규칙을 조정하는 편이 정확합니다.

ℹ 먼저 확인할 항목: 실패 직후 Clash 연결 로그에서 perplexity, 로그인 관련 호스트, CDN 주소를 각각 검색하세요. 모든 요청이 같은 프록시 그룹으로 나가는지, 일부가 DIRECT 또는 다른 자동 그룹으로 빠지는지 비교하면 원인 범위를 빠르게 좁힐 수 있습니다.

규칙 매칭과 정책 그룹부터 확인하기

Perplexity 접속 문제를 해결할 때 가장 먼저 볼 부분은 규칙의 순서입니다. Clash는 위에서 아래로 규칙을 평가하고 처음 매칭된 정책을 적용하므로, 넓은 GEOIP, RULE-SET, 광고 차단 목록이 Perplexity 관련 규칙보다 앞에 있으면 기대한 프록시 그룹에 도달하지 못할 수 있습니다. 반대로 너무 넓은 DOMAIN-SUFFIX 규칙을 먼저 넣으면 필요하지 않은 서비스까지 같은 노드로 보내져 속도와 안정성이 모두 나빠질 수 있습니다.

처음부터 모든 관련 도메인을 하나의 거대한 규칙 세트에 넣기보다는, 로그에 나타난 호스트를 임시 목록으로 만들고 하나씩 정책을 확인하는 것이 좋습니다. 예를 들어 메인 화면은 프록시 그룹을 사용하지만 스트리밍 API가 DIRECT로 찍힌다면 노드 품질보다 규칙 누락이 우선 문제입니다. 반대로 모든 요청이 동일한 그룹으로 가는데 TCP 연결 자체가 반복적으로 끊긴다면 그때는 노드, 전송 방식, 서버 지역을 비교해야 합니다.

규칙을 수정한 뒤에는 Clash 클라이언트에서 프로필을 다시 적용하고, 브라우저의 Perplexity 탭도 완전히 닫은 다음 새로 열어야 합니다. 서비스 워커나 오래된 연결이 남아 있으면 YAML을 고쳤는데도 이전 경로가 계속 사용되는 것처럼 보일 수 있습니다. 규칙 매칭 구조가 복잡하다면 라우팅 규칙 모범 사례와 규칙 우선순위 점검을 함께 참고하면 좋습니다.

Clash에서 Perplexity 시간 초과를 단계별로 수정하기

이제 실제로 원인을 분리해 보겠습니다. 아래 순서는 Clash Verge, Clash Verge Rev, Mihomo 계열 클라이언트에서 프로필과 연결 로그를 확인할 수 있다는 전제로 작성했습니다. 메뉴 이름은 클라이언트마다 조금 다르지만, 핵심은 “정책 선택 → DNS 확인 → 터널 확인 → 연결 재시험”의 순서를 지키는 것입니다.

  1. 현재 노드의 기본 상태를 확인합니다. 먼저 프록시 그룹에서 사용 중인 노드를 확인하고, 같은 노드로 일반 HTTPS 사이트와 Perplexity를 각각 열어 봅니다. 일반 사이트도 느리다면 Perplexity 규칙보다 노드 품질이나 회선 문제가 먼저입니다. 일반 사이트는 빠른데 Perplexity만 실패하면 다음 단계로 넘어갑니다.
  2. 연결 로그에서 정책명을 비교합니다. Perplexity를 새로고침하고 질문을 하나만 짧게 전송한 뒤 로그를 확인합니다. 화면을 구성하는 요청과 질문 응답 요청이 모두 같은 의도된 그룹으로 나가는지 봅니다. 일부 요청에 REJECT, DIRECT, 다른 지역의 자동 그룹이 섞이면 해당 호스트의 규칙을 보강합니다.
  3. DNS 응답과 주소를 확인합니다. DNS 모드가 로컬 네트워크의 차단이나 오염된 응답을 따르는지 살펴봅니다. fake-ip와 redir-host 중 무엇을 사용하는지는 환경에 따라 다르므로 무조건 변경하지 말고, 변경 전 프로필을 백업하세요. DNS를 바꾼 뒤에는 캐시를 비우고 클라이언트를 재시작한 다음 같은 요청을 다시 테스트합니다.
  4. TUN 모드 사용 여부를 분리합니다. 브라우저의 시스템 프록시만 사용하는 상태와 TUN 모드를 켠 상태에서 결과를 비교합니다. TUN에서만 실패한다면 운영체제의 가상 네트워크 인터페이스, 권한, 다른 VPN과의 충돌, 엄격한 라우팅 설정을 의심해야 합니다. 처음부터 TUN을 켜기보다 시스템 프록시로 접속이 되는지 확인한 뒤 TUN을 추가하는 편이 안전합니다.
  5. 스트리밍 요청을 다시 확인합니다. 검색 결과가 표시된 뒤 답변 생성 중에만 멈춘다면 짧은 페이지 요청과 장시간 연결의 차이를 봐야 합니다. 노드가 초기 연결은 허용하지만 오래 유지되는 스트리밍 세션을 불안정하게 처리할 수 있습니다. 다른 노드나 같은 지역의 안정적인 그룹으로 바꾸고, 동시에 여러 탭을 열지 않은 상태에서 한 번만 재현합니다. 
# 점검용 개념 예시
# 실제 호스트는 연결 로그에서 확인한 값으로 교체하세요.
- DOMAIN-SUFFIX,perplexity.ai,PERPLEXITY
- DOMAIN-SUFFIX,perplexity.com,PERPLEXITY
- MATCH,PROXY

위 예시는 출발점을 설명하기 위한 형태이며, 모든 환경에서 그대로 복사해야 하는 정답은 아닙니다. 구독 프로필이 업데이트될 때 로컬 규칙이 덮어써지는 클라이언트도 있으므로, 수정한 규칙이 실제 활성 프로필에 들어갔는지 반드시 확인하세요. 원격 프로필을 직접 편집할 수 없다면 로컬 오버라이드, 규칙 보강 기능, 또는 클라이언트가 제공하는 패치 방식을 사용해야 합니다. YAML을 저장한 뒤에는 파싱 오류가 없는지 확인하고, 오류가 발생하면 들여쓰기와 그룹 이름을 먼저 점검합니다.

DNS·TUN·노드 문제를 구분하는 방법

DNS 문제는 도메인이 잘못된 주소로 해석되거나 특정 호스트만 해석되지 않을 때 자주 나타납니다. 브라우저에 “사이트에 연결할 수 없음”이 즉시 표시되고 Clash 로그에 실제 연결 시도가 거의 없다면 DNS를 먼저 의심할 수 있습니다. 반면 로그에 도메인과 정책이 정상적으로 기록되지만 연결 시간이 길어진다면 DNS보다 TCP, TLS, 노드 품질을 봐야 합니다. 같은 도메인을 다른 네트워크에서 열어 비교하면 로컬 DNS의 영향을 분리하는 데 도움이 됩니다.

TUN 문제는 시스템 프록시를 따르지 않는 앱까지 처리하려고 할 때 발생하기 쉽습니다. TUN을 켠 뒤 브라우저뿐 아니라 다른 프로그램의 연결까지 갑자기 느려졌다면, 가상 인터페이스와 기존 VPN 또는 보안 프로그램이 충돌하는지 확인하세요. 운영체제 권한이 부족하거나 엄격한 라우팅 옵션이 켜져 있으면 일부 패킷이 잘못된 인터페이스로 나갈 수 있습니다. 먼저 TUN을 끄고 시스템 프록시 상태에서 Perplexity가 정상인지 확인하면 원인 구분이 쉬워집니다.

노드 문제는 동일한 규칙과 DNS 설정에서도 특정 노드만 실패할 때 드러납니다. 자동 선택 그룹의 지연 수치가 낮다고 해서 장시간 HTTPS 스트리밍까지 안정적인 것은 아닙니다. 짧은 ICMP 또는 HTTP 프로브는 통과하지만 실제 응답 스트림에서 끊기는 노드도 있습니다. 따라서 노드를 비교할 때는 핑 숫자 하나보다 Perplexity 화면 로딩, 질문 전송, 답변 스트리밍의 세 단계를 각각 확인해야 합니다.

⚠ 주의: DNS 모드, TUN, 시스템 프록시, 노드를 한 번에 모두 바꾸면 무엇이 해결했는지 알 수 없습니다. 변경할 때마다 한 가지 요소만 조정하고, 같은 질문과 같은 네트워크에서 재현 결과를 기록하세요. 회사·학교 네트워크에서는 내부 보안 정책과 서비스 이용 규정을 먼저 확인해야 합니다.

Clash for Windows처럼 오래된 클라이언트에서는 최신 Mihomo 규칙이나 TUN 옵션이 일부 지원되지 않을 수 있고, 반대로 새 GUI에서는 메뉴 이름이 바뀌어 예전 설정 안내가 그대로 적용되지 않을 수 있습니다. 프로필이 정상적으로 로드되었는지, 실제 코어가 Mihomo인지, 연결 로그가 현재 활성 프로필을 기준으로 표시되는지 확인하세요. Perplexity만을 위해 너무 넓은 우회 규칙을 추가하면 다른 업무 트래픽과 개인정보 보호 정책까지 영향을 받을 수 있으므로 관련 도메인만 좁게 지정하는 것이 좋습니다.

브라우저 확장 프로그램이나 보안 필터도 함께 점검할 필요가 있습니다. 광고 차단 확장, 추적 방지 기능, 기업용 HTTPS 검사 프로그램이 스트리밍 요청을 중간에서 닫으면 Clash 로그에는 정상 연결처럼 보이면서 페이지에서는 시간 초과가 나타날 수 있습니다. 시크릿 창 또는 확장 기능을 잠시 끈 별도 테스트로 브라우저 계층의 문제를 분리하고, 계정 로그인 문제와 네트워크 문제를 혼동하지 않도록 로그인하지 않은 기본 페이지와 인증 후 질문 전송을 나누어 확인하세요.

재발을 줄이는 운영 체크리스트

문제가 해결된 뒤에는 설정을 한 번에 크게 바꾸기보다 재현 가능한 기준을 남기는 것이 중요합니다. 현재 사용한 클라이언트와 코어 버전, 활성 프로필 이름, 선택한 정책 그룹, DNS 모드, TUN 상태, 테스트한 노드, 실패한 호스트를 간단히 기록해 두세요. 다음에 동일한 시간 초과가 발생했을 때 처음부터 모든 설정을 뒤지는 대신 이전 기록과 달라진 항목부터 비교할 수 있습니다.

같은 증상이 반복되면 연결 로그에서 새로 등장한 호스트가 있는지 먼저 확인하세요. 서비스가 프런트엔드, 인증, 검색 API, 스트리밍 서버를 분리하거나 CDN을 변경하면 예전에 작동하던 접미 규칙이 일부만 남을 수 있습니다. 반대로 아무 규칙도 바뀌지 않았는데 특정 노드에서만 문제가 발생한다면 구성 파일을 계속 수정하기보다 해당 노드를 제외하고 안정적인 그룹으로 교체하는 편이 빠릅니다. 노드 공급자의 지역과 전송 방식이 달라질 때에는 각각 한 번씩만 비교해 경로 차이를 확인합니다.

Perplexity 연결 문제를 해결할 때 다른 프록시 앱은 화면에 보이는 시스템 프록시 상태만 제공하거나, DNS와 TUN의 실제 경로를 한 곳에서 확인하기 어려운 경우가 있습니다. Clash V.CORE는 정책 그룹,连接日志, DNS와 TUN 상태를 함께 점검할 수 있어 “페이지는 열리지만 질문만 시간 초과”처럼 계층이 나뉜 문제를 추적하기 좋습니다. 설정을 직접 비교하고 로그 기반으로 안정적인 그룹을 선택하고 싶다면, 기능이 제한적인 단순 프록시 전환 도구보다 Clash V.CORE를 사용해 보세요. 현재 환경에 맞는 버전은 다운로드 페이지에서 확인할 수 있습니다.