이 글이 필요한 상황

Perplexity Comet을 설치했지만 검색 결과가 늦게 나오거나, 로그인 화면이 반복해서 새로고침되거나, 페이지는 열리는데 AI 답변 생성 단계에서 연결이 멈춘다면 브라우저 자체의 문제로만 보기는 어렵습니다. Comet은 일반적인 웹 브라우저처럼 보이지만 검색 요청, 계정 인증, 페이지 분석, 스트리밍 답변, 확장 기능 동기화 등 여러 HTTPS 연결을 동시에 사용합니다. 따라서 브라우저 창이 열리는 것과 실제 AI 서비스 트래픽이 안정적으로 처리되는 것은 서로 다른 문제일 수 있습니다.

국내 네트워크에서 Comet을 사용할 때는 특정 사이트만 느린 것이 아니라 검색은 되지만 답변이 멈춤, 로그인은 성공했는데 검색 결과가 비어 있음, 긴 페이지를 분석할 때만 타임아웃 같은 형태로 증상이 나타나기도 합니다. 이 글에서는 Clash Verge Rev와 Mihomo 계열 클라이언트를 기준으로, 필요한 트래픽만 프록시로 보내는 규칙 기반 설정을 설명합니다. 모든 국내 웹사이트를 무조건 프록시로 보내는 방식보다, Comet과 인증에 필요한 호스트를 확인하고 최소 범위로 분기하는 방법에 초점을 맞춥니다.

서비스 정책이나 네트워크 환경은 계정·지역·앱 버전에 따라 달라질 수 있습니다. 프록시는 연결 경로를 바꾸는 도구일 뿐이며, Perplexity 또는 Comet의 이용 약관과 회사·학교 네트워크 정책을 먼저 확인해야 합니다. 특히 회사 계정이나 민감한 문서를 사용하는 경우, 프록시 제공자와 노드 운영자가 트래픽을 어떻게 처리하는지 확인하고 비밀번호·API 키·개인 문서를 불필요하게 입력하지 않는 것이 안전합니다.

브라우저 문제와 프록시 경로 문제 구분하기

가장 먼저 할 일은 증상을 구체적으로 나누는 것입니다. Comet 아이콘을 눌러도 실행되지 않거나 창이 즉시 종료된다면 설치 파일, 운영체제 권한, 그래픽 가속 같은 로컬 문제일 가능성이 큽니다. 반대로 앱은 정상적으로 실행되고 일반 웹사이트도 열리지만 Perplexity 로그인·검색·답변 생성만 실패한다면 네트워크 경로와 DNS, 프록시 규칙을 먼저 살펴보는 편이 효율적입니다.

  • 로그인 화면 자체가 열리지 않음: 인증 도메인, 리디렉션, 쿠키 또는 TLS 연결이 중간에 끊겼을 수 있습니다.
  • 로그인은 되지만 검색 결과가 비어 있음: 검색 API나 결과 전달 호스트가 직접 연결로 빠졌거나 규칙에서 차단되었을 수 있습니다.
  • 답변 생성 중 멈춤: 스트리밍 연결, HTTP/2 세션, 장시간 연결을 처리하는 노드의 안정성을 확인해야 합니다.
  • 특정 웹사이트만 열리지 않음: Comet의 페이지 분석 대상이 별도 도메인으로 연결되며 DIRECT 또는 REJECT 규칙에 걸렸을 수 있습니다.
  • 모든 사이트가 느려짐: 글로벌 모드, 과부하된 노드, DNS 지연, TUN과 시스템 프록시의 중복 적용을 의심할 수 있습니다.

비교 테스트도 중요합니다. 같은 컴퓨터에서 일반 브라우저로 Perplexity 웹사이트를 열고, Comet에서는 동일한 계정으로 로그인해 보세요. 일반 브라우저만 성공한다면 두 앱이 서로 다른 프록시 설정을 사용하고 있을 수 있습니다. 반대로 두 앱 모두 같은 시점에 실패한다면 노드 상태나 회선, DNS 장애처럼 공통 경로에 있는 원인을 먼저 확인해야 합니다.

팁: 오류 메시지보다 실패한 시각과 요청 호스트가 더 유용할 때가 많습니다. Comet에서 로그인 버튼이나 새 검색을 실행한 직후 Clash 연결 로그를 확인하면 어떤 도메인이 DIRECT, PROXY, REJECT 중 어느 경로를 탔는지 비교할 수 있습니다.

Comet 트래픽은 왜 여러 도메인으로 나뉘는가

브라우저 화면에 표시되는 주소 하나만 프록시로 보내면 모든 기능이 해결될 것이라고 생각하기 쉽지만, 현대적인 AI 브라우저는 여러 서비스의 연결을 조합합니다. 메인 화면은 Perplexity 도메인에서 열리더라도 로그인 과정에서는 계정·OAuth 호스트로 이동하고, 검색 요청은 별도의 API 엔드포인트를 사용하며, 답변 스트리밍은 또 다른 연결을 유지할 수 있습니다. 분석 대상 웹사이트의 콘텐츠와 이미지, 자바스크립트는 원래 사이트에서 직접 불러오는 경우도 있습니다.

따라서 규칙을 만들 때는 처음부터 DOMAIN-SUFFIX를 너무 넓게 적용하지 않는 것이 좋습니다. 예를 들어 특정 키워드가 들어간 모든 도메인을 프록시로 보내면 광고, 이미지 CDN, 국내 서비스까지 같은 노드를 사용하게 되어 속도가 떨어질 수 있습니다. 반대로 메인 도메인 하나만 등록하면 인증이나 스트리밍 연결이 DIRECT로 빠져, 화면은 보이지만 답변이 끝까지 출력되지 않는 현상이 남을 수 있습니다.

실제 도메인은 Comet 버전, Perplexity의 서버 구성, 로그인 방식, 지역 설정에 따라 달라질 수 있으므로 공개된 예시를 그대로 확정 규칙으로 받아들이기보다 연결 로그로 확인해야 합니다. 먼저 Comet을 완전히 종료한 다음 다시 실행하고, 로그인·검색·답변 생성·외부 페이지 분석을 각각 한 번씩 수행합니다. 각 동작의 시작과 종료 시각을 기록하면 로그에서 관련 호스트를 묶기가 쉬워집니다.

1단계: Clash 클라이언트와 프로필 기본값 확인

이 글은 Windows와 macOS에서 사용할 수 있는 Clash Verge Rev를 기준으로 설명하지만, Mihomo 코어를 사용하는 다른 클라이언트에서도 원리는 같습니다. 먼저 앱이 실행 중인지, 프로필이 실제로 활성화되어 있는지, 코어가 재시작 루프에 빠지지 않았는지 확인합니다. 프로필 목록에 구독을 추가했더라도 현재 선택된 프로필이 기본 설정 파일이면, 화면에서 규칙을 수정해도 실제 연결에는 반영되지 않을 수 있습니다.

프로필을 활성화한 뒤에는 다음 항목을 순서대로 확인하세요.

  1. 노드 상태: 테스트 기능이나 연결 로그에서 선택한 노드가 응답하는지 확인합니다.
  2. 모드: 처음부터 글로벌 모드를 고정하지 말고, 규칙 모드에서 어떤 요청이 프록시로 분기되는지 확인합니다.
  3. 혼합 포트: mixed-port 번호를 확인하고 시스템 프록시와 터미널 설정이 같은 포트를 가리키는지 봅니다.
  4. DNS 모드: DNS 요청이 프록시와 충돌하지 않는지, 가상 IP 또는 일반 DNS 모드가 현재 프로필과 맞는지 확인합니다.
  5. TUN 상태: TUN을 켰다면 시스템 프록시와 동시에 이중으로 적용되지 않는지 점검합니다.

구독을 새로 가져온 직후에는 규칙 프로바이더와 DNS 설정이 함께 바뀔 수 있습니다. 예전에는 프록시로 처리되던 호스트가 새 프로필에서 DIRECT로 바뀌거나, 반대로 국내 서비스까지 우회 경로를 타는 경우가 있습니다. 설정을 한 번에 많이 바꾸지 말고, 프로필 활성화 후 기본 상태에서 Comet을 테스트한 다음 규칙을 한 그룹씩 추가하는 방식이 원인 추적에 유리합니다.

2단계: 구독 URL 가져오기와 프로필 점검

노드 구독을 사용하는 경우 제공자가 안내한 구독 URL을 준비합니다. URL에는 개인 식별 정보나 이용 권한이 포함될 수 있으므로 공개 게시판, 메신저 단체방, 저장소 이슈에 붙여 넣지 마세요. Clash Verge Rev의 프로필 또는 구독 관리 화면에서 URL을 추가한 뒤 업데이트를 실행하고, 생성된 프로필의 이름과 마지막 갱신 시각을 확인합니다.

구독을 가져왔다고 해서 곧바로 가장 빠른 노드가 선택되는 것은 아닙니다. 노드 이름에 한국, 일본, 싱가포르 등 지역이 표시되어도 실제 지연과 스트리밍 안정성은 시간대에 따라 달라집니다. Comet은 짧은 웹 요청만 하는 것이 아니라 답변을 일정 시간 유지할 수 있으므로, 단순 핑이 가장 낮은 노드보다 연결 끊김이 적은 노드가 더 적합할 수 있습니다.

확인 항목 권장 점검 방법 문제가 있을 때 나타나는 현상
구독 갱신 업데이트 시각과 프로필 변경 여부 확인 노드가 사라지거나 오래된 규칙이 계속 사용됨
노드 안정성 짧은 요청과 장시간 스트리밍을 모두 테스트 검색은 되지만 답변 중간에 연결 종료
포트 번호 클라이언트의 mixed-port와 OS 설정 비교 브라우저와 터미널의 연결 결과가 서로 다름
DNS 처리 로그의 DNS 오류와 규칙 매칭 결과 확인 로그인 리디렉션 실패, 간헐적 ENOTFOUND

프로필을 업데이트한 뒤 문제가 생겼다면 이전 프로필을 바로 삭제하지 말고 잠시 보관하세요. 새 프로필과 이전 프로필에서 동일한 검색을 실행하면 노드 문제인지 규칙·DNS 문제인지 비교할 수 있습니다. 단, 프로필 파일에 포함된 비공개 구독 URL은 백업 파일에 평문으로 남을 수 있으므로 다른 사람에게 전달하기 전 반드시 제거해야 합니다.

3단계: Comet 관련 요청을 규칙 모드로 분기하기

규칙 설정의 목표는 “모든 트래픽을 프록시로 보내기”가 아니라 “Comet이 안정적으로 통신해야 하는 요청만 같은 정책 그룹으로 보내기”입니다. 먼저 연결 로그에서 로그인, 검색, 답변 스트리밍 단계에 공통으로 등장하는 호스트와 각 단계에서 한 번씩만 등장하는 호스트를 구분합니다. 공통 호스트는 우선순위가 높고, 외부 페이지 분석 대상처럼 사용자마다 달라지는 호스트는 일반 웹 트래픽 정책을 따르게 두는 편이 관리하기 쉽습니다.

예시 규칙을 작성할 때는 자신의 실제 로그에 맞게 호스트를 교체해야 합니다. 다음은 구조를 이해하기 위한 형태이며, 임의의 도메인을 그대로 복사해 모든 환경의 정답으로 사용해서는 안 됩니다.

rules:
  - DOMAIN-SUFFIX,example-perplexity-host.com,AI-PROXY
  - DOMAIN,example-auth-host.com,AI-PROXY
  - DOMAIN-SUFFIX,example-cdn-host.com,AI-PROXY
  - MATCH,DIRECT

DOMAIN은 하나의 정확한 호스트에 적용할 때 적합하고, DOMAIN-SUFFIX는 하위 도메인까지 같은 정책을 적용할 때 사용합니다. DOMAIN-KEYWORD는 편리해 보이지만 의도하지 않은 호스트까지 매칭할 수 있으므로 마지막 수단으로 생각하세요. 규칙의 순서도 중요합니다. 더 구체적인 인증·API 호스트를 넓은 규칙보다 위에 배치하고, 마지막에만 기본 MATCH 처리를 둡니다.

일반 국내 사이트와 Perplexity 관련 요청을 모두 하나의 노드로 보내면 페이지 로딩이 오히려 느려질 수 있습니다. AI-PROXY 같은 별도 프록시 그룹을 만들고, 국내 검색·쇼핑·은행 사이트는 기존 DIRECT 정책을 유지하는 방식이 실용적입니다. 노드가 여러 개라면 자동 선택 그룹을 사용할 수 있지만, 테스트할 때는 노드를 하나로 고정해야 로그와 결과를 비교하기 쉽습니다.

팁: 규칙을 추가한 뒤에는 반드시 Clash의 연결 기록에서 실제 정책 이름을 확인하세요. YAML에 규칙을 작성했더라도 규칙 프로바이더가 먼저 매칭하거나 설정 파일이 저장되지 않으면 화면에서 기대한 AI-PROXY가 아니라 DIRECT가 표시될 수 있습니다.

4단계: 실제 동작으로 연결을 검증하기

설정이 끝났다면 한 번에 여러 기능을 실행하지 말고 단계별로 테스트합니다. 먼저 Comet을 완전히 종료하고 Clash 프로필을 다시 불러온 뒤 브라우저를 시작합니다. 시크릿 창에서 무조건 테스트하기보다는 일반 창과 별도로 비교하는 것이 좋습니다. 로그인 쿠키나 확장 기능 상태가 결과에 영향을 줄 수 있기 때문입니다.

  1. 초기 접속: Comet의 시작 페이지와 Perplexity 관련 화면이 열리는지 확인합니다.
  2. 인증: 로그인을 진행하고 리디렉션이 끝난 뒤 세션이 유지되는지 확인합니다.
  3. 짧은 질문: 짧은 검색어로 답변을 요청하고 첫 응답까지 걸린 시간을 기록합니다.
  4. 스트리밍 확인: 답변이 중간에 멈추지 않고 끝까지 출력되는지, Clash 로그에 연결 종료가 없는지 봅니다.
  5. 페이지 분석: 공개된 일반 웹페이지를 하나 열어 Comet의 분석 기능을 실행하고, 분석 대상 호스트가 과도하게 프록시로 몰리지 않는지 확인합니다.

각 테스트 사이에 노드를 바꾸거나 TUN을 켜고 끄면 무엇이 원인이었는지 판단하기 어렵습니다. 첫 번째 테스트에서는 기존 설정을 유지하고, 두 번째 테스트에서 노드만 바꾸고, 세 번째 테스트에서 규칙만 바꾸는 식으로 변수를 하나씩 분리하세요. 같은 질문을 반복할 때에는 계정 제한이나 서비스 응답 캐시가 결과에 영향을 줄 수 있으므로, 연결 성공 여부와 로그 상태를 함께 기록하는 것이 좋습니다.

답변이 생성되는 동안 연결 로그를 보면 스트리밍 요청이 계속 유지되는지 확인할 수 있습니다. 짧은 요청은 성공하지만 긴 답변에서만 끊긴다면 노드의 순간적인 패킷 손실, 연결 유지 시간, HTTP/2 처리 능력, TUN MTU를 의심할 수 있습니다. 이때 무작정 규칙을 넓히기보다 다른 노드에서 같은 요청을 실행해 경로 차이를 먼저 확인하세요.

DNS, TUN, 시스템 프록시 충돌 해결

Comet만 불안정한 것처럼 보여도 실제 원인은 DNS일 수 있습니다. 브라우저가 도메인 주소를 해석할 때 직접 회선의 DNS를 사용하고, 이후 연결은 프록시로 보내면 지역별 응답 주소나 차단 응답이 섞일 수 있습니다. 반대로 DNS까지 과도하게 우회하면 국내 웹사이트의 접속 속도가 떨어지거나 일부 서비스가 비정상적으로 동작할 수 있습니다. 중요한 것은 어떤 DNS 방식을 선택하느냐보다 현재 프로필의 DNS 설정, TUN 모드, 운영체제 네트워크 설정이 서로 같은 방향을 바라보는지입니다.

TUN과 시스템 프록시를 동시에 켠 상태에서는 요청이 두 번 가공되거나 예외 목록에 따라 서로 다른 경로를 탈 수 있습니다. 일반적인 브라우저 테스트라면 우선 시스템 프록시만 켜고 결과를 확인한 다음, Comet이 시스템 프록시를 무시할 때 TUN을 별도로 테스트하세요. TUN을 켠 뒤에는 VPN, 보안 프로그램, 다른 프록시 앱이 동시에 가상 네트워크 어댑터를 만들고 있지 않은지도 확인합니다.

Windows에서는 시스템 프록시 주소와 포트, 자동 구성 스크립트, 회사 보안 프로그램의 프록시 정책을 확인할 수 있습니다. macOS에서는 네트워크 서비스의 프록시 설정과 네트워크 확장 권한을 살펴보세요. 권한을 승인했는데도 연결이 바뀌지 않는다면 Clash를 완전히 종료한 후 다시 시작하고, 운영체제의 프록시 변경이 실제로 적용되었는지 다른 브라우저로 확인하는 것이 좋습니다.

보안과 유지 관리에서 주의할 점

구독 URL과 Clash 설정 파일은 단순한 환경 설정이 아니라 계정 권한과 연결된 정보일 수 있습니다. 구독 주소가 유출되면 다른 사람이 노드를 사용해 트래픽 한도나 계정 자원을 소모할 수 있고, 설정 파일에 삽입된 원격 규칙이 바뀌면 예상하지 못한 도메인이 다른 정책으로 분기될 수도 있습니다. 신뢰할 수 있는 제공자의 구독만 사용하고, 원격 규칙 프로바이더의 출처와 갱신 주기를 확인하세요.

Comet은 로그인 세션과 검색 기록, 웹페이지 내용을 다룰 수 있으므로 공용 노드에서는 특히 신중해야 합니다. 프록시 운영자가 HTTPS 본문을 직접 볼 수 있다는 뜻은 아니지만, 접속 시간·도메인·트래픽 양 같은 메타데이터가 노출될 수 있습니다. 금융 사이트, 사내 문서, 개인 의료 정보처럼 민감한 페이지를 분석할 때는 Comet의 기능보다 정보 보호 정책을 우선하세요.

설정이 안정된 뒤에는 프로필을 백업하되 구독 URL과 개인 토큰을 별도로 보호합니다. 업데이트 후 문제가 생기면 변경된 규칙, DNS 모드, 노드 목록을 이전 상태와 비교하세요. 매번 새로운 설정을 처음부터 만들기보다 정상 작동했던 프로필을 기준으로 한 항목씩 되돌리는 것이 복구가 빠릅니다. 또한 Clash와 Comet을 항상 최신 버전으로 유지하되, 업무 중인 컴퓨터에서는 업데이트 직후 자동으로 TUN이나 글로벌 모드가 켜지지 않는지 확인해야 합니다.

자주 묻는 질문

Comet은 열리는데 Perplexity 답변만 멈추는 이유는 무엇인가요?

초기 페이지와 답변 스트리밍이 서로 다른 호스트를 사용할 수 있기 때문입니다. Clash 연결 로그에서 답변을 요청한 시각의 호스트와 정책을 확인하고, 해당 요청이 DIRECT 또는 REJECT로 빠지는지 살펴보세요. 프록시로 분기되어도 답변 중간에 끊긴다면 다른 노드에서 장시간 연결을 비교해야 합니다.

글로벌 모드를 사용하면 더 쉽게 해결되지 않나요?

일시적인 원인 확인에는 도움이 될 수 있지만 장기 설정으로는 권장하지 않습니다. 글로벌 모드는 국내 서비스와 업데이트 서버까지 같은 노드로 보내 지연과 오류를 늘릴 수 있습니다. 글로벌 모드에서만 성공한다면 그 결과를 기준으로 실제 필요한 호스트를 찾아 규칙 모드로 좁히는 편이 안전합니다.

TUN을 반드시 켜야 하나요?

Comet이 운영체제 시스템 프록시를 정상적으로 따르는 환경이라면 mixed-port와 시스템 프록시만으로 충분할 수 있습니다. 앱이 프록시 설정을 무시하거나 일부 연결만 직접 전송한다면 TUN을 고려할 수 있지만, VPN·보안 프로그램·다른 프록시와 충돌할 수 있으므로 한 번에 하나씩 테스트해야 합니다.

구독을 가져온 뒤 설정이 갑자기 바뀌면 어떻게 하나요?

구독 프로필에 원격 규칙과 DNS 설정이 함께 포함되어 있을 수 있습니다. 업데이트 시각과 변경된 규칙을 확인하고, 이전에 정상 작동했던 프로필을 보관한 상태에서 새 프로필을 비교하세요. 구독 URL을 공개 채널에 공유하지 말고, 제공자에게 Comet 또는 Perplexity 연결에 필요한 정책을 문의하는 것도 방법입니다.

일부 브라우저용 프록시 확장은 탭별 적용이 간단하지만, 인증·스트리밍·백그라운드 요청이 섞인 AI 브라우저에서는 어떤 연결이 빠졌는지 확인하기 어렵고 플랫폼별 기능 차이도 큽니다. 반면 Clash는 연결 로그, 도메인 규칙, 노드 그룹, 시스템 프록시와 TUN 같은 선택지를 한곳에서 조정할 수 있어 Comet의 불안정한 요청만 분리해 점검하기 좋습니다. 필요한 트래픽만 프록시로 보내고 국내 사이트는 직접 연결하는 구성을 찾고 있다면, 자신의 운영체제에 맞는 Clash 클라이언트부터 확인해 보세요.

지금 Clash를 무료로 다운로드하고 자유로운 인터넷 경험을 →