2026-08-02 문제 해결 예상 읽기 시간 16분

Clash에서 ChatGPT 접속 안 될 때 타임아웃 해결법

Clash를 켜면 ChatGPT가 열리지 않거나 연결 시간이 초과되나요? Clash Verge Rev와 Mihomo 기준으로 프록시 모드, 노드 상태, 규칙 선택, DNS를 확인하고 필요할 때 TUN 모드와 노드 변경으로 문제를 해결하는 순서를 안내합니다.

ChatGPT 접속 타임아웃이 발생하는 구조부터 확인하기

Clash를 켠 뒤 ChatGPT가 열리지 않거나, 화면이 계속 로딩되다가 ERR_CONNECTION_TIMED_OUT, 504 Gateway Timeout 같은 오류를 표시하는 경우가 있습니다. 이 현상만 보고 곧바로 노드가 죽었다고 판단하기 쉽지만, 실제 원인은 여러 층으로 나뉩니다. ChatGPT 관련 도메인이 프록시 규칙에 매칭되지 않았거나, 시스템 프록시만 켜고 해당 애플리케이션의 연결은 우회하지 못했을 수도 있습니다. 반대로 규칙은 맞아도 노드의 국제 회선이 불안정하거나 DNS가 잘못된 IP를 반환해 연결이 시작되지 않는 경우도 있습니다.

먼저 타임아웃과 로그인 오류를 구분해야 합니다. 타임아웃은 서버와 연결을 맺거나 데이터를 주고받는 과정에서 일정 시간 응답이 없었다는 뜻입니다. 반면 로그인 실패, 인증 만료, 빈 화면은 연결 자체는 성립했지만 세션이나 브라우저 저장 데이터에서 문제가 발생했을 가능성이 큽니다. 따라서 아래 순서는 노드 응답 확인 → 규칙 매칭 확인 → DNS 확인 → 프록시 모드 확인 → TUN 점검 순서로 진행하는 것이 좋습니다. 처음부터 설정 파일을 크게 바꾸면 무엇이 해결에 영향을 줬는지 알 수 없게 됩니다.

증상	우선 의심할 항목	첫 번째 확인 방법
모든 ChatGPT 페이지가 타임아웃	노드, 규칙, 시스템 프록시	다른 노드로 전환한 뒤 연결 테스트
웹 브라우저는 되지만 데스크톱 앱은 실패	앱별 프록시 미지원 또는 TUN 비활성화	TUN 모드를 잠시 켜서 비교
페이지는 열리지만 로그인 단계에서 멈춤	DNS, 브라우저 쿠키, 인증 세션	시크릿 창과 다른 DNS 경로로 테스트
특정 노드에서만 실패	노드 품질, 출구 IP, 서버 혼잡	지역과 프로토콜이 다른 노드 2~3개 비교

1단계: 노드와 규칙이 실제로 ChatGPT에 적용되는지 확인

가장 먼저 Clash의 Connections 또는 연결 화면을 열고 ChatGPT를 새로고침하세요. 클라이언트마다 화면 이름은 다르지만, 현재 연결된 도메인과 선택된策略 그룹, 사용된规则를 확인하는 기능은 대부분 제공됩니다. 여기서 요청이 전혀 보이지 않는다면 브라우저가 캐시된 오류를 표시하는 것이거나, 애플리케이션이 Clash의 프록시 포트를 사용하지 않는 상황일 수 있습니다. 요청이 보이는데 REJECT, DIRECT로 처리된다면 규칙부터 수정해야 합니다.

ChatGPT 사용 중에는 하나의 주소만 호출되지 않습니다. 메인 화면 외에도 로그인, 정적 리소스, API, 인증 및 스트리밍 연결에 여러 도메인이 사용될 수 있습니다. 특정 도메인 하나만 프록시로 보내고 나머지를 직결하면 첫 화면은 열리지만 로그인이나 대화 생성 단계에서 멈출 수 있습니다. 다만 모든 도메인을 무조건 임의로 추가하기보다는 연결 로그에서 실제 요청된 호스트를 확인해 필요한 범위를 넓히는 방식이 안전합니다.

테스트를 위해 일시적으로 대상 도메인을 신뢰할 수 있는 프록시 그룹으로 보내는 규칙을 상단에 배치할 수 있습니다. 규칙은 위에서 아래로 평가되므로, 너무 일반적인 GEOIP, DOMAIN-SUFFIX, MATCH 규칙보다 앞에 있어야 합니다.

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

위 예시의 ChatGPT는 실제 설정에 존재하는 프록시 그룹 이름으로 바꿔야 합니다. 그룹 이름이 다르면 규칙을 적어도 요청은 정상 처리되지 않습니다. 구독 설정이 자동으로 생성한 규칙을 사용한다면 같은 도메인을 중복으로 추가하기보다, 연결 로그에서 현재 매칭된 그룹을 먼저 확인하세요. 설정을 저장한 뒤에는 코어를 재시작하거나 설정을 다시 적용해야 변경 사항이 반영됩니다.

2단계: 노드 품질과 출구 IP를 교차 테스트하기

노드 목록에서 지연시간 테스트를 실행한 뒤, 한 노드의 결과만 보고 결론을 내리지 마세요. 같은 지역의 다른 노드, 다른 지역의 노드, 가능하면 다른 프로토콜의 노드를 각각 하나씩 골라 비교해야 합니다. ChatGPT 연결에서는 단순한 TCP 지연시간뿐 아니라 TLS 연결 안정성, 장시간 연결 유지, 서버 출구 IP의 평판도 영향을 줄 수 있습니다. 지연시간이 80ms로 표시되어도 실제 HTTPS 요청이 반복적으로 끊긴다면 정상적인 사용이 어렵습니다.

테스트 결과	가능성이 높은 원인	판단
한 노드만 타임아웃	노드 과부하 또는 출구 IP 문제	해당 노드를 교체하고 설정은 유지
같은 지역 노드만 실패	지역 회선 또는 제공업체 측 장애	다른 지역과 프로토콜로 비교
모든 노드에서 동일하게 실패	규칙, DNS, 시스템 프록시, TUN	로컬 설정을 중심으로 진단
브라우저만 성공하고 앱은 실패	앱이 로컬 HTTP 프록시를 사용하지 않음	TUN 또는 앱별 프록시 설정 확인

노드를 바꿀 때는 여러 설정을 동시에 수정하지 않는 것이 중요합니다. 예를 들어 노드 변경과 DNS 변경과 TUN 활성화를 한꺼번에 하면 접속이 성공하더라도 원인을 특정할 수 없습니다. 먼저 같은 규칙과 DNS를 유지한 채 노드만 바꾸고, 성공 여부를 기록하세요. 서로 다른 세 노드에서 모두 같은 타임아웃이 발생하면 노드 교체를 반복할 이유가 줄어듭니다. 그때는 로컬 설정 단계로 넘어가야 합니다.

DNS 해석과 HTTPS 연결이 끊기는 지점 점검

ChatGPT 도메인이 잘못된 주소로 해석되면 규칙이 정확해도 연결되지 않습니다. Clash의 DNS 설정에서 enable이 꺼져 있거나, 시스템 DNS와 Clash DNS가 서로 다른 결과를 반환하는 환경에서는 특히 증상이 일관되지 않을 수 있습니다. 브라우저에서 주소가 열리지 않는다고 해서 반드시 DNS만의 문제는 아니지만, 연결 로그에 도메인이 반복적으로 해석 실패로 나타나거나 IP 연결 단계에서 멈춘다면 DNS를 우선 확인할 가치가 있습니다.

mihomo 기반 클라이언트에서는 다음처럼 기본 DNS와 해외 도메인용 DNS를 분리하는 구성을 사용할 수 있습니다. 단, 사용 중인 코어 버전과 클라이언트의 설정 병합 방식에 따라 지원 필드가 다를 수 있으므로 기존 설정을 백업한 뒤 적용하세요.

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  nameserver-policy:
    "+.openai.com":
      - https://1.1.1.1/dns-query
    "+.chatgpt.com":
      - https://1.1.1.1/dns-query

default-nameserver는 DNS 서버 주소 자체를 해석할 때 사용할 서버이므로 일반적으로 IP 주소를 넣습니다. DoH 주소를 여기에 넣으면 초기 해석을 위해 다시 도메인 해석이 필요해지는 순환 문제가 생길 수 있습니다. 또한 fake-ip 모드를 사용하면서 특정 도메인을 fake-ip-filter에 잘못 넣으면 예상과 다른 결과가 나올 수 있으니, 변경 후에는 DNS 캐시를 비우고 Clash 코어를 재시작하세요.

DNS를 바꿨는데도 계속 타임아웃이면 같은 변경을 반복하지 말고, 브라우저에서 다른 HTTPS 사이트와 ChatGPT를 비교하세요. 다른 해외 사이트도 모두 실패하면 DNS보다는 노드나 네트워크 경로 문제일 가능성이 큽니다. 반대로 다른 사이트는 정상인데 ChatGPT 관련 주소만 실패한다면 해당 도메인의 규칙, 출구 IP, 연결 유지 문제를 집중적으로 확인해야 합니다.

3단계: 시스템 프록시와 TUN 모드를 구분해서 테스트하기

Clash의 일반적인 시스템 프록시 모드는 운영체제의 HTTP 및 SOCKS 프록시 설정을 바꾸는 방식입니다. 브라우저처럼 시스템 프록시를 따르는 프로그램은 이 방법으로 처리되지만, 모든 애플리케이션이 해당 설정을 따르는 것은 아닙니다. 일부 데스크톱 앱은 자체 네트워크 라이브러리를 사용하거나 프록시 설정을 무시하므로 브라우저는 연결되는데 앱만 타임아웃이 발생할 수 있습니다.

이 경우에는 먼저 시스템 프록시가 켜져 있고 로컬 포트가 올바른지 확인하세요. 일반적으로 혼합 포트는 7890처럼 표시되지만, 실제 번호는 클라이언트 설정에서 확인해야 합니다. 브라우저의 수동 프록시 설정에 오래된 포트가 남아 있거나, 다른 프록시 프로그램이 같은 포트를 차지하고 있으면 Clash 화면은 실행 중이어도 요청이 전달되지 않습니다.

브라우저와 앱의 차이를 확인하는 가장 빠른 방법은 TUN 모드를 잠시 활성화하는 것입니다. TUN은 가상 네트워크 인터페이스를 만들어 시스템의 IP 트래픽을 Clash 코어로 전달하므로, 시스템 프록시를 지원하지 않는 프로그램도 처리할 수 있습니다. 다만 관리자 권한, 가상 인터페이스, 라우팅 설정이 필요하고 다른 VPN이나 보안 프로그램과 충돌할 수 있습니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

Clash Verge Rev나 Mihomo 계열 클라이언트에서는 설정 화면의 TUN 스위치를 사용하는 편이 안전합니다. TUN을 켠 뒤에는 기존 VPN, 다른 가상 네트워크 도구, 중복된 DNS 리디렉션 기능을 잠시 끄고 테스트하세요. TUN 활성화 후 앱이 연결되면 원인은 노드가 아니라 해당 앱이 시스템 프록시를 사용하지 않았던 것으로 좁혀집니다. 반대로 TUN에서도 브라우저와 앱이 모두 실패하면 규칙과 노드, DNS를 다시 확인해야 합니다.

타임아웃을 재현하고 해결 여부를 판정하는 최종 순서

설정을 바꾼 뒤에는 브라우저 탭만 새로고침하지 말고, 테스트 조건을 일정하게 맞추는 것이 좋습니다. 먼저 Clash에서 현재 연결과 로그를 지운 다음, 선택한 노드를 고정합니다. 그 상태에서 일반 페이지 접속, 로그인 페이지 접속, 새 대화 생성 순서로 확인하세요. 각 단계에서 실패하면 시간과 오류 문구를 기록하면 다음 판단이 쉬워집니다. 페이지가 열렸다는 사실만으로 해결됐다고 판단하면 로그인이나 스트리밍 연결에서 같은 문제가 다시 나타날 수 있습니다.

Clash 연결 로그에서 ChatGPT 관련 도메인이 실제로 보이는지 확인합니다.
해당 요청이 DIRECT나 REJECT가 아닌 의도한 프록시 그룹으로 처리되는지 확인합니다.
현재 노드에서 실패하면 같은 규칙을 유지한 채 다른 노드 두 개를 비교합니다.
모든 노드에서 실패하면 DNS 캐시, nameserver, 시스템 프록시 포트를 점검합니다.
브라우저만 되고 앱이 실패하면 TUN을 켜서 앱별 프록시 미지원 여부를 확인합니다.
변경 후에는 코어를 재시작하고, 기존 브라우저 세션이나 오래된 DNS 캐시를 정리한 뒤 다시 테스트합니다.

가장 흔한 해결 패턴은 규칙 그룹 이름을 바로잡고, ChatGPT 관련 요청이 프록시로 처리되도록 규칙 순서를 조정한 뒤, 문제가 지속될 때만 노드를 교체하는 것입니다. 특정 노드에서만 타임아웃이 발생한다면 설정을 과도하게 고치지 말고 그 노드를 제외하세요. 모든 노드에서 동일하게 실패할 때는 DNS와 TUN을 점검하고, 다른 해외 서비스까지 함께 실패한다면 Clash 외부의 네트워크 상태도 확인해야 합니다. 원인을 한 층씩 분리하면 설정을 무작정 갈아엎지 않고도 접속 실패 지점을 찾을 수 있습니다.