ChatGPT 접속이 안 될 때 Clash 타임아웃 해결 방법

타임아웃 증상부터 정확히 확인하기

ChatGPT가 Clash를 사용할 때만 열리지 않는다면 인터넷 전체가 끊긴 것이 아니라 특정 연결 경로에서 시간 초과가 발생했을 가능성이 큽니다. 브라우저가 계속 로딩되다가 ERR_TIMED_OUT을 표시하거나, 로그인 화면은 열리지만 대화 목록과 응답이 나타나지 않는 경우가 대표적입니다. ChatGPT 웹 서비스는 단순한 정적 페이지뿐 아니라 API 요청, 인증, 스트리밍 응답, WebSocket 또는 장시간 유지되는 HTTPS 연결을 함께 사용하므로 일반 웹사이트 하나가 열린다는 사실만으로 정상 동작을 판단하기 어렵습니다.

먼저 Clash를 완전히 끈 상태와 실행한 상태를 비교하세요. Clash를 종료하면 ChatGPT가 즉시 열리고 다시 켜면 타임아웃이 발생한다면 노드, 규칙, DNS, 로컬 포트 또는 시스템 프록시 중 하나가 원인입니다. 반대로 Clash를 꺼도 동일하게 실패한다면 현재 네트워크, 브라우저 쿠키, 계정 인증 또는 서비스 측 상태를 먼저 확인해야 합니다.

증상	우선 의심할 항목	확인 방법
페이지 자체가 오래 로딩됨	노드 연결, DNS, 라우팅	다른 노드와 직접 연결을 비교
로그인은 되지만 답변이 멈춤	스트리밍 연결, WebSocket, 불안정한 노드	새 대화와 다른 브라우저에서 재현
특정 도메인만 실패	잘못된 rules 또는 도메인별 DNS 정책	규칙 로그에서 실제 매칭 결과 확인
모든 사이트가 실패	Clash 포트, 시스템 프록시, TUN	`127.0.0.1:7890` 수신 여부 확인
간헐적으로 연결됨	노드 품질, 패킷 손실, DNS 변동	지연 시간뿐 아니라 반복 요청 결과 비교

노드와 규칙이 ChatGPT 트래픽을 올바르게 보내는지 확인

가장 흔한 원인은 ChatGPT 관련 도메인이 차단 노드나 만료된 노드로 전달되는 경우입니다. 설정이 mode: rule이라면 트래픽은 rules를 위에서부터 순서대로 검사합니다. ChatGPT 도메인에 대한 규칙보다 앞에 있는 광범위한 DOMAIN-SUFFIX, GEOIP 또는 FINAL 규칙이 먼저 매칭되면 예상과 다른 정책 그룹이 선택될 수 있습니다.

ChatGPT 접속을 점검할 때는 웹 주소 하나만 보지 말고 실제 로그에 나타나는 여러 대상 도메인을 확인해야 합니다. 서비스 구성은 변경될 수 있으므로 특정 도메인 목록을 영구적인 정답으로 간주해서는 안 됩니다. 일반적으로 기본 웹 접속 주소, 인증 관련 주소, API 요청 주소와 정적 리소스 주소가 서로 다를 수 있습니다. 로그에 표시된 도메인을 기준으로 정책 그룹이 의도한 노드 또는 자동 선택 그룹으로 향하는지 확인하세요.

mode: rule
rules:
  - DOMAIN-SUFFIX,openai.com,ChatGPT
  - DOMAIN-SUFFIX,chatgpt.com,ChatGPT
  - MATCH,DIRECT

위 예시는 구조를 설명하기 위한 단순한 형태입니다. 실제 설정에서는 이미 존재하는 규칙을 무작정 삭제하지 말고, 구독 제공자가 관리하는 규칙과 충돌하는지 먼저 확인하세요. 정책 그룹 이름도 실제 YAML의 이름과 정확히 일치해야 합니다. 화면에 “ChatGPT”라는 그룹이 보여도 YAML에서 이름이 GPT Proxy라면 규칙 대상에 잘못된 이름을 입력한 것입니다.

정책 로그에서 최종 선택 결과 확인

FlClash 또는 사용 중인 Clash 클라이언트에서 로그 화면을 엽니다.
브라우저에서 ChatGPT를 새로고침하고 실패한 시각의 요청을 찾습니다.
대상 도메인, 연결 방향, 선택된策略 그룹과 실제 노드 이름을 기록합니다.
같은 정책 그룹에서 다른 노드를 선택한 뒤 동일한 요청을 반복합니다.
모든 노드에서 실패하면 규칙보다 DNS, 시스템 프록시 또는 네트워크 환경을 계속 점검합니다.

DIRECT로 연결했을 때만 실패하고 프록시 노드에서는 성공한다면 현재 네트워크에서 해당 서비스로의 직접 연결이 제한된 것일 수 있습니다. 반대로 모든 노드에서 실패하고 일반 사이트도 열리지 않는다면 노드 선택 문제로 단정하지 마세요. 만료된 인증서, 서버의 과부하, QUIC 또는 UDP 품질 저하도 타임아웃을 만들 수 있습니다.

DNS와 TUN 모드가 만드는 연결 경로 확인

DNS 문제는 “노드는 연결되지만 특정 서비스만 타임아웃”이라는 형태로 나타나기 쉽습니다. 시스템 DNS가 반환한 주소와 mihomo가 사용하는 DNS 응답이 다르면, 브라우저는 접속할 수 없는 주소를 선택하거나 지역에 맞지 않는 경로로 연결할 수 있습니다. 특히 TUN 모드에서 DNS 하이재킹을 사용하는 경우에는 운영체제의 DNS 설정만 바꾸어도 실제 요청 경로가 달라지지 않을 수 있습니다.

사용 방식	주요 확인 지점	주의할 점
시스템 프록시	HTTP·HTTPS 프록시 주소와 포트	프록시를 읽지 않는 앱은 우회될 수 있음
TUN	가상 인터페이스, 자동 라우팅, DNS 하이재킹	권한과 다른 VPN 앱의 충돌 확인 필요
브라우저 자체 프록시	브라우저 확장 프로그램과 별도 프록시 설정	시스템 프록시와 중복 설정하지 않기
분할 DNS	`nameserver-policy`와 fake-ip 예외	도메인별 응답 정책이 규칙과 일치해야 함

문제 해결을 위해 먼저 복잡한 DNS 설정을 모두 추가하기보다는 현재 모드를 단순화하는 것이 좋습니다. TUN을 사용 중이라면 잠시 TUN을 끄고 시스템 프록시만 활성화하여 브라우저에서 접속을 테스트하세요. 이 상태에서 정상 작동하면 코어 자체보다 TUN 라우팅, DNS 하이재킹, 다른 VPN 드라이버와의 충돌 가능성이 커집니다. 반대로 시스템 프록시에서도 실패하지만 TUN에서만 성공한다면 브라우저가 시스템 프록시를 제대로 읽고 있는지 확인해야 합니다.

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'

위 설정은 참고용 예시이며, 모든 네트워크에서 동일하게 사용할 수 있는 만능 설정은 아닙니다. 사내망, 학교망, 공유기 내부 주소를 사용한다면 로컬 도메인과 내부 DNS를 별도로 보존해야 합니다. ipv6: false는 IPv6 경로에서만 실패하는지 확인하기 위한 임시 진단 항목으로 사용할 수 있으며, 변경 후에는 DNS 캐시와 브라우저 연결을 새로 시작해야 합니다.

실제로 한 변수씩 바꾸며 테스트하기

이제 설정을 크게 수정하지 않고 원인을 분리해 보겠습니다. 테스트 결과를 메모하면서 한 번에 하나의 변수만 변경해야 합니다. 노드, DNS, TUN을 동시에 바꾸면 문제가 해결되어도 어느 항목이 효과가 있었는지 알 수 없습니다.

브라우저 새 세션 만들기: ChatGPT 탭을 닫고 시크릿 창 또는 다른 브라우저에서 다시 접속합니다. 확장 프로그램과 오래된 로그인 쿠키의 영향을 줄일 수 있습니다.
Clash 로그 초기화: 기존 로그를 지운 뒤 ChatGPT의 기본 페이지를 새로고침합니다. 요청이 로그에 전혀 나타나지 않으면 브라우저가 Clash를 통과하지 않는 것입니다.
현재 노드 확인: 정책 그룹에서 안정성이 확인된 다른 노드를 수동 선택합니다. 자동 선택 그룹의 측정 결과만 믿지 말고 두세 차례 새로고침합니다.
TUN을 잠시 끄기: 시스템 프록시를 지원하는 브라우저만 남겨 테스트합니다. TUN에서만 실패하면 가상 인터페이스와 DNS 경로를 조사합니다.
DNS 캐시 갱신: Clash의 DNS 캐시를 비우고 코어를 재시작한 뒤 같은 브라우저 세션에서 다시 확인합니다.
규칙 매칭 확인: 로그에 표시된 ChatGPT 관련 도메인이 원하는 정책 그룹으로 전달되는지 확인합니다.
기본 연결 테스트: 터미널에서 프록시 포트를 지정해 HTTPS 응답을 확인합니다.

curl -I -L --connect-timeout 10 --max-time 30 \
  -x http://127.0.0.1:7890 \
  https://chatgpt.com/

명령어가 HTTP/2 200, HTTP/2 301 또는 인증 페이지에 해당하는 응답을 반환한다고 해서 로그인과 대화 기능까지 정상이라는 뜻은 아닙니다. 이 테스트의 목적은 로컬 포트가 열려 있고 TLS 연결과 기본 HTTP 요청이 완료되는지 확인하는 것입니다. Could not connect to server가 나오면 Clash가 해당 포트에서 수신하지 않거나 포트 번호가 실제 설정과 다릅니다. Operation timed out이면 선택한 노드나 DNS 경로를 바꾸어 비교하세요.

설정에 mixed-port: 7890이 없다면 실제 mixed-port, http-port 또는 socks-port 값을 사용해야 합니다. SOCKS 포트만 있는 경우에는 명령어의 프록시 형식을 -x socks5h://127.0.0.1:포트로 바꿀 수 있습니다. socks5h는 도메인 해석을 프록시 측에 요청하므로 로컬 DNS 문제와 비교하는 데 도움이 됩니다.

시스템 프록시와 고급 설정을 마지막으로 점검

Clash가 정상 실행 중이어도 운영체제가 다른 포트를 가리키고 있으면 브라우저는 실제 코어를 사용하지 않습니다. Windows, macOS, Linux의 시스템 프록시 설정에서 HTTP와 HTTPS 주소가 같은 로컬 수신 포트를 가리키는지 확인하세요. 한쪽은 127.0.0.1:7890, 다른 쪽은 예전에 사용하던 127.0.0.1:7891로 남아 있는 경우가 있습니다. 자동 구성 스크립트(PAC)를 사용한다면 PAC가 ChatGPT 관련 도메인을 DIRECT로 보내고 있지 않은지도 확인해야 합니다.

브라우저 확장 프로그램에 별도의 프록시가 설치되어 있다면 우선 비활성화하세요. 시스템 프록시, 브라우저 확장, TUN이 동시에 트래픽을 처리하면 요청이 서로 다른 노드로 분산되거나 프록시 루프가 생길 수 있습니다. Clash 로그에 같은 요청이 반복해서 나타나고 연결이 닫히지 않는다면 중복 프록시 또는 잘못된 로컬 프록시 주소를 의심할 수 있습니다.

안정성을 위한 권장 원칙

allow-lan: false 유지: 다른 기기에서 로컬 포트에 접근할 필요가 없다면 외부 LAN 수신을 열지 않습니다.
컨트롤 포트와 프록시 포트 구분: external-controller: 127.0.0.1:9090은 관리 API이며 브라우저 프록시 주소로 사용하지 않습니다.
IPv6는 단계적으로 확인: IPv4에서는 성공하고 IPv6에서만 실패하는 경우에만 임시로 IPv6 비활성화를 테스트합니다.
규칙을 과도하게 추가하지 않기: ChatGPT 도메인을 여러 그룹에 중복 등록하면 최종 매칭 순서를 추적하기 어려워집니다.
노드 자동 테스트 URL 확인: 자동 선택 그룹이 응답하지 않는 테스트 URL을 사용하면 실제 서비스와 관계없이 노드를 잘못 평가할 수 있습니다.
코어 로그 수준 조정: 진단 중에는 log-level: info를 사용하고, 해결 후에는 필요한 범위에서 로그를 낮춰 민감한 요청 정보 노출을 줄입니다.

마지막으로 다른 네트워크에서 같은 노드와 같은 설정을 비교하세요. 가정용 회선에서는 실패하지만 모바일 핫스팟에서 성공하면 공유기 DNS, 통신사 경로 또는 네트워크 방화벽 가능성이 높습니다. 두 네트워크 모두 실패하고 다른 노드에서도 동일하다면 노드 제공자 상태, 계정 인증, ChatGPT 서비스 상태를 확인해야 합니다. 여러 설정을 한꺼번에 바꾸기보다 “직접 연결과 프록시”, “노드 A와 노드 B”, “시스템 프록시와 TUN”, “현재 DNS와 단순 DNS”를 순서대로 비교하는 것이 가장 빠른 해결 방법입니다.