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

ChatGPT 타임아웃 증상부터 정확히 구분하기

Clash를 켠 뒤 ChatGPT에 접속하면 화면이 계속 로딩되거나, 로그인 페이지는 열리지만 대화 목록이 나타나지 않거나, 질문을 보낸 후 응답 생성 중에 연결이 끊기는 경우가 있습니다. 이때 화면에 표시되는 오류는 비슷해도 실제 원인은 서로 다를 수 있습니다. 브라우저 요청이 Clash에 도달하지 않는 문제, Clash가 잘못된 정책 그룹으로 보내는 문제, 선택한 노드가 OpenAI 관련 도메인이나 장시간 연결을 안정적으로 처리하지 못하는 문제, DNS 또는 브라우저의 자체 네트워크 기능이 충돌하는 문제가 대표적입니다.

먼저 Clash의 Connections 또는 연결 목록을 열어 둔 상태에서 ChatGPT 페이지를 새로고침해 보세요. chatgpt.com, openai.com, auth.openai.com 같은 요청이 전혀 나타나지 않는다면 브라우저가 Clash를 사용하지 않는 것입니다. 요청은 표시되지만 계속 TIMEOUT 또는 FAILED로 끝난다면 프록시 모드, 정책 그룹, 노드 또는 DNS를 점검해야 합니다. 페이지는 열리지만 답변을 생성할 때만 멈춘다면 짧은 연결 테스트는 통과했지만 스트리밍 연결이 불안정한 상황일 가능성이 큽니다.

프록시 모드와 노드가 ChatGPT에 맞는지 확인하기

가장 먼저 현재 모드를 확인합니다. Direct 모드는 모든 트래픽을 직접 연결하므로 ChatGPT에 프록시가 필요하거나 현재 네트워크에서 해당 서비스 연결이 원활하지 않다면 접속이 실패합니다. Global 모드는 모든 요청을 선택한 프록시로 보내므로, 문제의 범위를 좁히는 테스트에 유용합니다. Rule 모드는 도메인과 규칙셋에 따라 요청을 분기하므로 평소 사용에는 적합하지만, 잘못된 규칙 하나 때문에 로그인과 API 요청이 서로 다른 경로로 나뉠 수 있습니다.

1. Clash 클라이언트에서 모드를 임시로 Global로 바꿉니다.
2. 정책 그룹에서 지연 시간이 지나치게 높거나 최근 테스트에서 timeout이 나온 노드를 선택하지 말고, 정상 응답하는 다른 노드를 고릅니다.
3. 브라우저에서 ChatGPT를 완전히 새로고침하고, 가능하면 새 비공개 창에서 로그인 페이지와 새 대화를 각각 확인합니다.
4. Global 모드에서 정상 작동하면 다시 Rule 모드로 돌아가 연결 목록에서 실제로 어떤 정책 그룹이 선택되었는지 확인합니다.

ChatGPT는 단순한 정적 웹페이지가 아닙니다. 웹 화면을 불러오는 요청 외에도 로그인, 설정 조회, 대화 목록, 파일 업로드, 답변 스트리밍 등에 여러 HTTPS 연결을 사용합니다. 따라서 테스트 주소의 지연 시간이 낮다는 사실만으로 ChatGPT 사용 품질을 보장할 수 없습니다. 노드 테스트가 통과하더라도 특정 목적지와의 TLS 연결이나 장시간 스트리밍에서 끊길 수 있으므로, 실제로 새 대화를 보내 응답이 끝까지 생성되는지 확인해야 합니다.

실제로 10분 안에 원인을 좁히는 점검 순서

이제 설정을 무작정 수정하지 않고, 요청이 어느 구간에서 멈추는지 확인해 보겠습니다. Windows의 Clash Verge Rev, Clash for Windows 계열이나 macOS의 ClashX 계열, 모바일의 Mihomo 기반 클라이언트에서도 메뉴 이름은 조금 다르지만 같은 논리로 확인할 수 있습니다.

1. 연결 목록을 준비합니다. Clash의 Connections 화면을 열고 브라우저에서 ChatGPT를 새로고침합니다. chatgpt.com과 openai.com 요청이 기록되는지 확인합니다.
2. Global 모드에서 노드를 고정합니다. 자동 선택 그룹 대신 테스트가 성공한 노드를 하나 직접 선택합니다. 자동 그룹이 장애 노드를 계속 재선택하면 결과가 흔들릴 수 있습니다.
3. 브라우저 확장을 잠시 끕니다. 별도 프록시 확장, 광고 차단 확장, 개인정보 보호 확장이 요청이나 쿠키를 차단할 수 있으므로 비공개 창 또는 확장을 끈 별도 프로필에서 시험합니다.
4. 로그인과 대화를 나누어 테스트합니다. 로그인 페이지가 열리는지, 로그인 후 대화 목록이 표시되는지, 짧은 질문에 답변이 끝까지 생성되는지를 각각 확인합니다.
5. Rule 모드로 돌아갑니다. Global에서는 성공했지만 Rule에서 실패한다면 정책 그룹의 선택 결과와 도메인 규칙을 비교합니다. ChatGPT 관련 도메인이 DIRECT로 빠지거나 차단 그룹으로 들어가면 해당 규칙을 수정합니다.
6. 한 번에 한 항목만 변경합니다. 노드를 바꾼 뒤 결과를 기록하고, 그 다음에 DNS나 브라우저 설정을 변경합니다. 이런 방식이면 원인을 재현하기도 쉽습니다.

명령줄에서도 로컬 Clash 포트까지 요청이 전달되는지 확인할 수 있습니다. 믹스 포트가 기본값인 경우 다음처럼 실행합니다.

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

응답 헤더가 돌아오면 로컬 포트와 선택한 노드 사이의 기본 HTTPS 요청은 작동한다는 뜻입니다. 단, 이 명령 하나가 ChatGPT의 로그인이나 답변 스트리밍까지 보장하는 것은 아닙니다. 명령은 성공하지만 브라우저에서만 실패한다면 브라우저 쿠키, 확장 기능, DoH 또는 QUIC 설정을 별도로 살펴보세요.

분할 규칙과 DNS 때문에 일부 요청만 실패하는 경우

Rule 모드에서 ChatGPT가 불안정하다면 단순히 chatgpt.com 하나만 확인해서는 부족합니다. 로그인과 API, 정적 리소스, 인증 과정에 사용되는 관련 도메인이 서로 다른 정책으로 분기될 수 있기 때문입니다. 연결 목록에서 실제 요청의 대상과 적용된策略를 확인하고, 필요한 도메인이 같은 프록시 정책을 사용하도록 구성해야 합니다. 구체적인 도메인 목록은 서비스 측에서 변경할 수 있으므로 오래된 목록을 그대로 복사하기보다 현재 연결 목록을 기준으로 확인하는 것이 안전합니다.

다음과 같은 규칙 구조는 개념을 설명하기 위한 예시입니다. 실제 설정에서는 사용 중인 규칙셋과 정책 그룹 이름에 맞게 바꾸세요.

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

규칙 순서도 중요합니다. 위에서부터 먼저 일치하는 규칙이 적용되므로, 앞쪽에 광범위한 GEOSITE,cn,DIRECT 또는 다른 차단 규칙이 있으면 뒤의 ChatGPT 규칙까지 도달하지 않을 수 있습니다. 규칙셋을 사용하는 경우에는 ChatGPT 관련 규칙이 실제로 로드되었는지, 정책 그룹 이름이 존재하는지, 마지막 MATCH 규칙이 의도하지 않은 DIRECT로 설정되어 있지 않은지 확인하세요.

DNS와 fake-ip 예외 확인하기

DNS 오류는 페이지 전체가 아니라 로그인, 이미지, 파일 업로드 같은 일부 기능만 실패하게 만들 수 있습니다. mihomo 설정에서 내장 DNS를 사용한다면 enable, enhanced-mode, nameserver가 정상인지 확인합니다. fake-ip 모드에서 특정 요청이 가상 주소와 호환되지 않는다면 해당 도메인을 fake-ip-filter에 예외로 추가해 비교할 수 있습니다. 다만 처음부터 예외를 무분별하게 늘리면 DNS 요청이 시스템 경로로 빠질 수 있으므로, 연결 목록과 오류 재현 결과를 근거로 최소한만 추가해야 합니다.

브라우저의 보안 DNS 또는 DNS over HTTPS가 켜져 있으면 브라우저가 Clash의 DNS 처리 경로를 우회할 수 있습니다. 문제를 분석하는 동안에는 브라우저의 보안 DNS를 잠시 끄고, Clash의 DNS 동작만으로 다시 시험해 보세요. Windows에서는 ipconfig /flushdns로 시스템 캐시를 비운 뒤 브라우저를 재시작할 수 있습니다. Clash에서 DNS를 변경한 뒤에는 기존 연결이 남아 결과가 섞이지 않도록 클라이언트와 브라우저를 함께 재시작하는 것이 좋습니다.

브라우저, TLS, TUN 모드의 충돌 점검

모드와 노드를 바꿔도 ChatGPT가 계속 타임아웃된다면 브라우저의 연결 방식이 원인일 수 있습니다. Chromium 계열 브라우저는 QUIC 또는 HTTP/3를 사용할 수 있는데, 네트워크와 프록시 조합에 따라 UDP 기반 연결이 불안정해질 수 있습니다. 연결 목록에 원하는 TCP HTTPS 요청이 나타나지 않고 브라우저에서만 멈춘다면 HTTP/3 사용을 잠시 제한한 뒤 다시 비교해 보세요. 브라우저 설정 변경은 버전마다 위치가 다르므로 실험 후에는 원래 값을 기록해 두는 편이 안전합니다.

또한 날짜와 시간이 크게 어긋나면 TLS 인증서 검증이 실패할 수 있습니다. 운영체제의 시간 자동 설정을 켜고, 보안 프로그램이 HTTPS 트래픽을 검사하는 기능을 사용한다면 일시적으로 비활성화해 원인을 비교합니다. 회사나 학교 네트워크의 인증 프록시가 별도로 설치되어 있는 경우에는 Clash의 연결과 충돌할 수 있으므로 해당 네트워크의 정책을 확인해야 합니다.

TUN 모드를 사용하는 경우에는 시스템 프록시보다 더 넓은 범위의 트래픽을 가로채지만, 가상 네트워크 어댑터와 DNS 하이재킹 권한이 필요합니다. TUN을 켠 뒤에만 문제가 생긴다면 다음 항목을 확인하세요.

• Clash에 TUN 권한 또는 관리자 권한이 부여되어 있는지 확인합니다.
• 다른 VPN, 방화벽, 보안 프로그램이 가상 어댑터를 동시에 제어하고 있지 않은지 확인합니다.
• 브라우저의 시스템 프록시와 TUN을 동시에 사용하면서 중복 경로가 만들어지지 않았는지 확인합니다.
• TUN을 잠시 끄고 시스템 프록시만 사용했을 때 ChatGPT가 정상인지 비교합니다.

재발을 줄이는 안정적인 구성과 최종 확인

문제가 해결된 뒤에는 가장 복잡한 설정을 그대로 유지하기보다, ChatGPT에 필요한 경로를 단순하게 만드는 것이 좋습니다. 일상적인 웹사이트는 Rule 모드로 사용하되 ChatGPT 관련 요청은 하나의 안정적인 정책 그룹으로 보내고, 장애가 잦은 노드는 자동 선택 그룹에서 제외합니다. url-test 그룹을 사용한다면 테스트 URL의 응답만으로 최종 품질을 판단하지 말고, 실제 대화 생성과 파일 업로드를 피크 시간대에도 확인하세요.

구독을 업데이트한 직후 다시 타임아웃이 발생했다면 노드 목록뿐 아니라 규칙셋과 정책 그룹도 함께 바뀌었는지 살펴봅니다. 원격 설정 제공자가 새로운 규칙을 내려주면서 기존의 사용자 규칙을 덮어쓸 수 있습니다. 로컬에서 꼭 유지해야 하는 규칙이 있다면 제공자의 사용자 규칙 기능을 사용하거나, 업데이트 후 적용 순서를 다시 확인하세요. 구독 링크에는 인증 정보가 포함될 수 있으므로 설정 파일과 링크를 공개된 장소에 올리지 않는 것도 중요합니다.

최종적으로 다음 네 가지를 통과하면 기본적인 타임아웃 문제는 대부분 정리된 것입니다.

• Global 모드에서 고정한 정상 노드로 ChatGPT 페이지가 열립니다.
• Rule 모드에서도 연결 목록의 관련 요청이 의도한 정책 그룹으로 전달됩니다.
• 로그인, 대화 목록, 새 질문 전송, 답변 스트리밍이 모두 끝까지 완료됩니다.
• 브라우저를 재시작하거나 Clash 설정을 업데이트한 뒤에도 같은 결과가 재현됩니다.

여전히 문제가 지속된다면 서비스 장애 여부와 계정 상태도 확인해야 합니다. 모든 기기와 모든 노드에서 동시에 실패한다면 로컬 설정만의 문제로 단정하지 말고, 다른 네트워크에서 같은 계정으로 비교해 보세요. 반대로 한 기기에서만 실패한다면 해당 기기의 Clash 클라이언트 버전, DNS 캐시, TUN 권한, 브라우저 프로필을 집중적으로 점검하는 것이 효율적입니다.