Clash에서 ChatGPT 접속 안 될 때 원인별 해결법과 타임아웃 설정

B-01먼저 접속 실패 증상을 유형별로 구분하기

ChatGPT가 열리지 않는다고 해서 곧바로 노드를 바꿀 필요는 없습니다. 브라우저에서 페이지가 완전히 로드되지 않는지, 로그인 화면은 열리지만 대화 요청만 실패하는지, 또는 “Network error”, “Request timed out” 같은 메시지가 표시되는지에 따라 점검 순서가 달라집니다. 특히 ChatGPT는 한 개의 도메인만 사용하는 서비스가 아니므로 메인 페이지가 열린다는 사실만으로 전체 경로가 정상이라고 판단하기 어렵습니다. 웹 화면, 인증 요청, API 요청, 정적 리소스가 서로 다른 호스트로 연결될 수 있기 때문입니다.

먼저 Clash를 완전히 끈 상태와 켠 상태를 비교하고, 그다음 현재 선택한 노드로 일반적인 HTTPS 사이트에 접속해 보세요. 모든 사이트가 실패하면 ChatGPT 전용 설정이 아니라 로컬 프록시 경로의 문제일 가능성이 높습니다. 반대로 다른 해외 서비스는 정상인데 ChatGPT만 실패한다면 규칙, DNS, TLS 또는 특정 도메인에 대한 노드 호환성을 집중적으로 확인해야 합니다.

B-02프록시 모드와 규칙 매칭 상태 확인

Clash의 시스템 프록시 모드는 운영체제 프록시를 따르는 애플리케이션의 HTTP·HTTPS 요청을 로컬 포트로 보내는 방식입니다. TUN 모드는 가상 네트워크 인터페이스를 통해 시스템 프록시를 사용하지 않는 프로그램까지 처리할 수 있지만, 권한과 DNS 설정이 추가로 필요합니다. 따라서 “Clash가 실행 중”이라는 상태와 “ChatGPT 요청이 Clash를 통과 중”이라는 상태는 서로 다를 수 있습니다.

Windows와 macOS에서 시스템 프록시 스위치를 켠 뒤에도 브라우저가 직접 연결을 사용한다면 브라우저 확장 프로그램이나 수동 프록시 설정이 우선 적용되고 있을 수 있습니다. Proxy Switcher 계열 확장 프로그램을 잠시 끄고, 브라우저의 프록시 출처가 시스템 설정으로 되어 있는지 확인하세요. TUN을 사용하는 경우에는 TUN 서비스 권한이 허용되었는지, 다른 VPN이 동시에 실행되고 있지 않은지, 가상 어댑터가 정상적으로 생성되었는지도 살펴봐야 합니다.

다음 단계는 연결 로그입니다. Clash Verge Rev 또는 mihomo 기반 클라이언트의 Logs 화면에서 ChatGPT 접속 직후 발생한 요청을 확인하고, 해당 요청이 DIRECT인지 프록시 그룹인지 살펴보세요. 의도한 그룹이 아닌 DIRECT로 매칭된다면 규칙이 누락된 것이고, 프록시 그룹으로 매칭되는데도 실패한다면 선택 노드나 DNS 경로를 확인해야 합니다. 규칙은 위에서 아래로 평가되므로 너무 넓은 DOMAIN-SUFFIX 또는 앞쪽의 MATCH가 뒤의 세부 규칙을 가로채지 않도록 배치해야 합니다.

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

위 예시는 설명을 위한 기본 형태입니다. 실제 구독 설정에 이미 같은 도메인에 대한 규칙이나 정책 그룹이 있다면 이름을 중복해서 만들지 말고 기존 그룹명을 사용하세요. 서비스 도메인은 변경될 수 있으므로 고정 목록을 영구적인 정답으로 취급하기보다는 접속 로그에서 실제 요청 호스트를 확인하고, 필요한 범위만 추가하는 방식이 안전합니다.

B-03DNS와 TLS 단계에서 발생하는 실패 점검

규칙 매칭은 맞는데 연결이 시작되지 않는다면 DNS 응답이 잘못되었거나 DNS 요청 자체가 다른 경로로 빠지는 경우를 의심할 수 있습니다. 특히 TUN과 fake-ip 모드를 함께 사용할 때는 DNS 설정과 예외 목록이 서로 맞아야 합니다. 브라우저가 도메인을 해석하지 못하면 Clash 로그에 해당 도메인 요청이 제대로 나타나지 않거나, 연결 대상이 예상과 다른 주소로 표시될 수 있습니다.

우선 DNS 모드를 바꾸기 전에 현재 상태를 기록하세요. fake-ip를 사용 중이라면 특정 도메인이 fake IP 예외 목록에 들어가 있는지 확인하고, redir-host로 잠시 전환해 증상이 달라지는지 비교할 수 있습니다. 어느 한쪽이 항상 우수한 것은 아닙니다. fake-ip은 규칙 처리와 TUN 환경에 편리하지만 일부 애플리케이션과 호환성 문제가 생길 수 있고, redir-host는 원래 도메인 정보를 보존하는 대신 환경에 따라 DNS 누수가 발생하거나 규칙 처리가 복잡해질 수 있습니다.

DNS 서버를 여러 개 등록했더라도 모든 서버가 같은 방식으로 동작하는 것은 아닙니다. 해외 도메인 질의가 로컬 DNS로 먼저 나가 잘못된 응답이나 지연을 받는다면, nameserver-policy 또는 도메인별 DNS 정책으로 분리할 수 있습니다. 다만 설정을 여러 번 바꾼 뒤에는 브라우저 DNS 캐시와 Clash의 DNS 캐시가 남아 있을 수 있으므로 클라이언트와 브라우저를 재시작해 새 결과를 확인하세요.

B-04직접 테스트로 노드·포트·DNS를 분리 진단하기

이제 설정을 한 번에 전부 바꾸지 말고, 현재 선택된 노드와 로컬 포트가 실제로 요청을 전달하는지 직접 시험합니다. Clash의 혼합 포트가 7890이 아니라면 클라이언트 화면에 표시된 값을 사용해야 합니다. 터미널에서 다음 명령을 실행해 응답 코드와 실패 시간을 확인하세요.

curl -x http://127.0.0.1:7890 https://chatgpt.com/ -I -m 15

1. 즉시 Connection refused가 나오면 노드보다 로컬 포트가 문제입니다. Clash가 실행 중인지, 포트 번호가 맞는지, 다른 프로그램이 포트를 점유했는지 확인하세요.
2. 15초 동안 응답이 없다가 종료되면 로컬 포트는 열려 있지만 선택 노드와 목적지 사이의 연결이 완료되지 않은 것입니다. 같은 그룹에서 다른 노드를 선택해 다시 실행하세요.
3. HTTP 응답 헤더가 돌아오면 기본 HTTPS 경로는 통과한 것입니다. 이때 브라우저만 실패한다면 브라우저 캐시, 확장 프로그램, 쿠키 또는 브라우저의 보안 정책을 별도로 점검하세요.
4. 명령마다 결과가 달라지면 자동 선택 그룹의 노드 전환 상태나 노드 서버의 순간적인 혼잡을 확인하세요. 진단 중에는 자동 선택 대신 특정 노드를 고정하는 편이 좋습니다.

DNS를 별도로 비교하려면 운영체제의 도메인 해석 결과와 Clash 로그의 연결 대상이 같은지 확인합니다. 단, nslookup 결과가 곧 실제 프록시 목적지라는 뜻은 아닙니다. DNS 요청이 로컬에서 처리되는지, Clash DNS 모듈이 처리하는지에 따라 결과가 달라질 수 있으므로 명령어 하나만으로 결론을 내리지 말고 로그와 함께 판단해야 합니다.

B-05타임아웃 설정을 조정하는 기준

타임아웃은 연결이 실패하기까지 기다리는 시간이지, 느린 노드를 빠르게 만드는 옵션이 아닙니다. 너무 짧으면 지연이 큰 정상 노드가 실패로 판정되고, 너무 길면 죽은 노드가 자동 선택 그룹에 오래 남아 전체 사용성이 나빠집니다. 따라서 먼저 노드 상태와 규칙을 확인한 뒤 측정 환경에 맞춰 조금씩 조정해야 합니다.

노드 자동 테스트나 프록시 제공자 상태 확인에 쓰이는 health-check 설정에서는 보통 테스트 URL, 검사 주기, 타임아웃을 함께 지정합니다. 예시는 다음과 같습니다.

proxy-providers:
  subscription:
    type: http
    url: "https://example.com/subscription"
    path: ./profiles/subscription.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300
      timeout: 5000

여기서 timeout: 5000은 모든 웹 요청의 제한 시간이 아니라 상태 검사 한 번에 허용하는 시간으로 이해해야 합니다. 사용하는 mihomo 버전과 클라이언트가 해당 필드를 지원하는지 확인하고, 구독 제공자가 생성한 설정을 직접 수정할 때는 업데이트 과정에서 덮어써질 수 있다는 점도 고려하세요. 상태 검사 URL이 현재 네트워크에서 차단되거나 불안정하면 실제 ChatGPT 사용 가능 여부와 무관하게 노드가 나쁘게 표시될 수 있습니다.

• 일반적으로 3~5초는 빠른 노드 선별에 적합하지만, 먼 지역의 노드를 모두 실패로 처리할 수 있습니다.
• 8~15초는 지연이 큰 네트워크에서 비교적 안정적인 범위지만, 실패 노드의 제거가 늦어집니다.
• 타임아웃을 늘려도 모든 노드가 같은 시점에 실패하면 구독, 방화벽, DNS, 네트워크 차단을 먼저 확인해야 합니다.

B-06변경 후 재현 테스트와 최종 체크리스트

설정을 바꾼 뒤에는 여러 항목을 동시에 수정하지 말고 한 단계씩 재현하세요. 먼저 특정 노드를 고정하고 시스템 프록시 또는 TUN 중 하나만 사용합니다. 다음으로 연결 로그에서 ChatGPT 관련 요청이 의도한 정책 그룹으로 들어가는지 확인하고, 브라우저의 기존 탭을 닫은 뒤 새 창에서 로그인과 대화 전송을 각각 시험합니다. 페이지는 열리지만 메시지만 실패한다면 메인 도메인 외의 요청이 다른 정책으로 빠지는지 로그를 다시 살펴보세요.

문제가 해결된 뒤에는 임시로 추가한 광범위한 규칙을 정리하고, 필요 이상으로 긴 타임아웃을 원래 값에 가깝게 되돌리는 것이 좋습니다. 자동 선택 그룹에서 특정 노드만 안정적이었다면 그 노드를 고정해 며칠간 관찰한 뒤 다른 노드와 비교하세요. 반대로 특정 노드만 계속 실패한다면 전체 설정을 다시 만드는 대신 해당 노드의 서버 주소, 포트, 인증 정보, TLS와 전송 계층만 점검하면 됩니다.