DOC-01

ChatGPT만 타임아웃되는 주요 원인부터 분리하기

첫 단계는 “인터넷 전체가 안 되는가”와 “ChatGPT 관련 요청만 실패하는가”를 구분하는 것입니다. Clash를 끈 상태에서 일반 웹사이트가 열리지 않는다면 로컬 네트워크, 공유기, 운영체제의 DNS 또는 인터넷 회선부터 확인해야 합니다. 반대로 일반 사이트는 정상이고 ChatGPT만 실패한다면 프록시를 거치지 않는 직접 연결, 특정 노드의 목적지 연결 실패, DNS 응답 오류가 우선순위가 됩니다.

ChatGPT 웹 서비스는 하나의 주소만 사용하는 구조가 아닙니다. 로그인과 계정 확인, 정적 리소스, 대화 요청, 보안 검증 과정에서 여러 OpenAI 관련 호스트와 콘텐츠 전송 도메인이 사용될 수 있습니다. 따라서 chatgpt.com 하나만 규칙에 추가했다고 모든 요청이 반드시 같은 경로로 처리되는 것은 아닙니다. 브라우저 개발자 도구를 사용한다면 실패한 요청의 호스트 이름과 오류 유형을 확인할 수 있지만, 무작정 모든 외부 요청을 프록시로 보내는 방식은 진단에 적합하지 않습니다.

DOC-02

프록시 모드와 규칙 누락을 확인하는 방법

Clash의 Rule 모드에서는 설정 파일의 rules를 위에서 아래로 검사하며, 처음으로 일치한 규칙의 정책을 적용합니다. ChatGPT 관련 도메인이 DIRECT로 처리되는 규칙에 먼저 걸리면, 선택한 프록시 노드가 아무리 정상이어도 해당 요청은 프록시를 통과하지 않습니다. 반대로 모든 요청을 하나의 프록시로 보내는 Global 모드에서 정상적으로 접속된다면, 노드보다는 Rule 모드의 분기 결과를 의심할 수 있습니다.

진단할 때는 먼저 현재 모드를 Rule로 두고 Clash의 연결 목록 또는 요청 로그를 엽니다. ChatGPT 페이지를 새로고침한 뒤 chatgpt.com 및 실제로 실패한 관련 호스트를 찾아 적용된 정책 그룹을 확인합니다. 표시된 정책이 DIRECT인지, 올바른 프록시 그룹인지, 또는 REJECT인지에 따라 다음 조치가 달라집니다. 단순히 화면에 주소가 보인다는 사실만으로는 충분하지 않으며, 실제 연결의最终 정책을 확인해야 합니다.

테스트용으로 다음과 같이 대상 도메인을 프록시 그룹에 보내는 규칙을 앞쪽에 배치할 수 있습니다. 여기서 Proxy는 예시 이름이므로 실제 설정에 정의된 프록시 그룹명으로 바꿔야 합니다.

rules:
  - DOMAIN-SUFFIX,chatgpt.com,Proxy
  - DOMAIN-SUFFIX,openai.com,Proxy
  - MATCH,Proxy

DOMAIN-SUFFIX는 지정한 도메인과 하위 도메인을 함께 매칭합니다. 다만 서비스가 사용하는 모든 호스트를 미리 추측해 과도하게 추가하는 것은 권장하지 않습니다. 먼저 로그에서 실제 실패 호스트를 확인하고, 필요한 범위만 규칙으로 보완하세요. 또한 설정 파일에 이미 더 넓은 DOMAIN-KEYWORD, GEOIP, RULE-SET 규칙이 앞에 있다면 새 규칙이 실행되지 않을 수 있습니다. 규칙은 위치가 곧 우선순위이므로 수정 후에는 반드시 설정을 다시 적용해야 합니다.

Global 모드는 원인 분리를 위한 임시 테스트로만 사용하는 편이 좋습니다. Global에서 접속되고 Rule에서 실패하면 규칙 문제일 가능성이 높지만, Global에서도 실패하면 노드, DNS, 목적지 연결 또는 브라우저 세션 문제를 계속 확인해야 합니다. 테스트가 끝난 뒤에는 필요한 트래픽만 분기하도록 Rule 모드로 되돌리는 것이 안정적입니다.

DOC-03

실제 점검 순서: 노드, 연결 로그, 브라우저를 차례로 비교하기

아래 절차는 여러 값을 동시에 바꾸지 않고 한 단계씩 원인을 좁히는 방법입니다. 사용하는 클라이언트에 따라 메뉴 이름은 다를 수 있지만, 핵심은 현재 선택된 프로필과 코어가 실제 트래픽을 처리하고 있는지 확인하는 데 있습니다.

1. 활성 프로필을 확인합니다. 구독을 새로 가져온 뒤 예전 테스트 프로필이 계속 활성화되어 있지 않은지 확인합니다. 현재 노드 목록과 규칙 목록이 방금 갱신한 설정에 포함되어 있어야 합니다.
2. 정상 노드 두세 개를 비교합니다. 지연 시간이 지나치게 높거나 테스트가 타임아웃인 노드는 잠시 제외합니다. 한 노드에서 실패하고 다른 노드에서 성공하면 클라이언트보다 해당 노드 또는 출구 IP의 문제일 가능성이 큽니다.
3. 시스템 프록시를 켭니다. 브라우저가 시스템 프록시를 사용하도록 설정되어 있는지 확인합니다. Clash 화면에서 시스템 프록시가 켜져 있어도 브라우저 내부에 별도 프록시가 지정되어 있으면 경로가 달라질 수 있습니다.
4. 연결 로그를 열고 ChatGPT를 새로고침합니다. 요청이 기록되지 않으면 브라우저가 Clash를 통과하지 않는 것입니다. 요청은 기록되지만 정책이 DIRECT이면 규칙을 확인하고, 프록시 정책으로 표시되면서 실패하면 노드 또는 DNS를 확인합니다.
5. 브라우저 세션을 정리합니다. 확장 프로그램, 광고 차단기, 오래된 쿠키, 회사 보안 솔루션이 로그인이나 스트리밍 요청을 방해할 수 있습니다. 시크릿 창 또는 확장 프로그램을 끈 별도 프로필에서 같은 노드로 다시 테스트합니다.
6. 변경 사항을 하나씩 원복합니다. 테스트를 위해 Global 모드, 사용자 지정 DNS, TUN을 켰다면 결과를 기록한 후 하나씩 원래 상태로 돌려 어떤 항목이 영향을 주었는지 확인합니다.

Windows에서는 명령 프롬프트에서 nslookup chatgpt.com을 실행해 DNS 응답이 반환되는지 확인할 수 있습니다. macOS와 Linux에서는 dig chatgpt.com 또는 같은 목적의 DNS 조회 도구를 사용할 수 있습니다. 이 명령은 접속 가능 여부를 보장하는 검사가 아니라 이름이 IP 주소로 해석되는지 확인하는 보조 수단입니다. DNS 조회가 성공해도 프록시 연결이 실패할 수 있고, 반대로 브라우저가 자체 DNS를 사용하면 명령 결과와 실제 브라우저 경로가 다를 수 있습니다.

DOC-04

DNS 오류와 HTTPS 연결 실패를 구분하기

DNS 문제는 도메인 이름을 IP 주소로 바꾸는 단계에서 발생하고, 프록시 연결 문제는 해석 이후 목적지와 실제 세션을 맺는 단계에서 발생합니다. 두 오류는 모두 브라우저에서 “사이트에 연결할 수 없음”으로 표시될 수 있으므로 Clash 로그와 DNS 로그를 함께 봐야 합니다. 도메인이 해석되지 않거나 반복해서 다른 주소를 반환된다면 DNS 경로를 점검하고, 해석은 정상인데 TCP 또는 TLS 연결이 시간 초과라면 노드와 목적지 연결을 우선 확인합니다.

mihomo 계열 설정에서는 일반적으로 dns.enable, nameserver, fallback, enhanced-mode가 서로 다른 역할을 합니다. nameserver는 기본 해석 서버이고, fallback은 조건에 따라 대체 해석 경로로 사용됩니다. fake-ip 모드는 도메인에 가상 IP를 매핑해 연결 시 원래 도메인 정보를 코어가 유지하도록 하며, redir-host는 해석된 실제 주소를 사용하는 방식입니다. 특정 모드가 모든 네트워크에서 항상 더 좋은 것은 아니므로 현재 클라이언트와 운영체제의 호환성을 기준으로 판단해야 합니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.cloudflare.com/dns-query
    - https://dns.google/dns-query
  fallback:
    - tls://1.1.1.1
    - tls://8.8.8.8

위 예시는 구조를 설명하기 위한 예시이며, 실제 적용 전에는 사용 중인 mihomo 코어가 해당 DNS 주소 형식과 옵션을 지원하는지 확인해야 합니다. DNS over HTTPS나 DNS over TLS를 사용하면 로컬 네트워크의 일반 DNS 간섭을 줄일 수 있지만, 암호화된 DNS 서버 자체에 접근할 수 없는 네트워크에서는 오히려 조회 지연이 생길 수 있습니다. DNS 설정을 바꾼 뒤에는 Clash 코어를 재시작하고, 브라우저의 DNS 캐시와 기존 연결도 정리한 다음 다시 테스트해야 합니다.

DNS 하이재킹 방지 또는 DNS hijack 기능은 TUN 환경에서 DNS 요청을 Clash가 처리하도록 유도하는 데 사용할 수 있습니다. 그러나 운영체제의 다른 VPN, 보안 프로그램, 가상 네트워크 어댑터가 동시에 DNS를 가로채면 충돌이 발생할 수 있습니다. 따라서 DNS 옵션을 여러 개 중복 활성화하기보다 현재 클라이언트가 제공하는 기본 템플릿을 기준으로 한 항목씩 변경하세요.

DOC-05

브라우저 외 앱까지 실패할 때 TUN 모드 적용하기

브라우저는 정상인데 ChatGPT 데스크톱 앱이나 다른 클라이언트형 프로그램만 접속하지 못한다면 해당 프로그램이 시스템 프록시를 따르지 않을 수 있습니다. 시스템 프록시 모드는 애플리케이션이 운영체제의 프록시 값을 읽어야 작동하지만, TUN 모드는 가상 네트워크 인터페이스와 라우팅 테이블을 통해 더 낮은 네트워크 계층에서 트래픽을 처리합니다. 이 차이 때문에 프록시 설정을 무시하는 일부 프로그램에는 TUN이 유효한 해결책이 될 수 있습니다.

TUN을 켜기 전에는 다른 VPN, Docker나 가상 머신의 네트워크 어댑터, 기업용 보안 소프트웨어를 먼저 확인합니다. 이러한 구성 요소가 이미 라우팅 테이블이나 DNS를 관리하고 있으면 Clash의 TUN과 충돌할 수 있습니다. Windows에서는 최초 활성화 시 관리자 권한과 가상 네트워크 드라이버 설치 승인이 필요할 수 있으며, macOS에서는 네트워크 확장 또는 관련 권한 허용이 요구될 수 있습니다. 권한 요청을 거부한 상태에서 스위치만 반복해서 켜는 것은 해결되지 않습니다.

1. Clash의 TUN 메뉴에서 기능을 활성화하고, 필요한 시스템 권한을 승인합니다.
2. DNS 설정과 자동 라우팅 옵션을 확인합니다. 이미 다른 VPN이 실행 중이면 먼저 종료한 뒤 비교합니다.
3. 브라우저와 ChatGPT 앱을 모두 완전히 종료한 다음 TUN을 켠 상태에서 다시 실행합니다.
4. 접속 로그에서 트래픽이 TUN을 통해 들어오는지, 대상 요청이 올바른 정책 그룹으로 전달되는지 확인합니다.
5. 인터넷 전체가 끊기면 TUN을 끄고 시스템 프록시 모드로 복구한 뒤, 권한·라우팅·DNS 충돌을 하나씩 조사합니다.

TUN은 문제를 자동으로 해결하는 만능 스위치가 아닙니다. 잘못된 규칙은 TUN에서도 그대로 적용되고, 사용할 수 없는 노드는 TUN을 켜도 정상화되지 않습니다. 목적이 브라우저 접속 확인뿐이라면 먼저 시스템 프록시와 Rule 매칭을 정상화하고, 프록시를 인식하지 않는 앱까지 관리해야 할 때만 TUN을 추가하는 순서가 안전합니다.

DOC-06

마지막 판정과 재발 방지 기준

대부분의 ChatGPT 접속 시간 초과는 다음 네 가지 결과 중 하나로 정리할 수 있습니다. 첫째, 모든 노드가 실패하면 구독 만료, 로컬 네트워크 또는 노드 제공 측 장애를 의심합니다. 둘째, 특정 노드만 실패하면 다른 노드로 교체해 출구 IP 또는 서버 상태를 비교합니다. 셋째, Global에서는 성공하고 Rule에서는 실패하면 규칙 순서와 실제 매칭 정책을 수정합니다. 넷째, 브라우저는 성공하지만 앱만 실패하면 시스템 프록시 미지원 여부를 확인하고 필요한 경우 TUN을 적용합니다.

설정이 정상화된 뒤에는 변경한 값을 기록해 두는 것이 좋습니다. 활성 프로필 이름, 사용한 노드, 동작 모드, DNS 모드, TUN 사용 여부, 실패한 호스트와 로그의 오류 유형을 함께 남기면 다음 장애에서 같은 검사를 반복하지 않아도 됩니다. 특히 timeout, connection refused, DNS 조회 실패, TLS 오류는 서로 다른 단계의 문제이므로 같은 해결책을 일괄 적용하지 않는 것이 중요합니다.