먼저 오류 유형과 적용 중인 프록시 경로를 구분하세요
Clash를 켰는데 ChatGPT 페이지가 열리지 않는다고 해서 곧바로 노드 장애라고 단정할 수는 없습니다. 브라우저가 시스템 프록시를 사용하지 않는 경우, 현재 모드가 직접 연결로 설정된 경우, 규칙이 예상과 다른 그룹으로 연결을 보내는 경우에도 비슷한 증상이 나타납니다. 반대로 페이지는 열리지만 로그인이나 대화 전송에서 멈춘다면 인증 도메인, DNS, TLS 연결 또는 특정 노드의 안정성을 따로 살펴봐야 합니다.
먼저 오류가 발생하는 위치를 기록하세요. 브라우저에서 chatgpt.com 자체가 열리지 않는지, 로그인 화면까지는 보이지만 인증이 끝나지 않는지, 대화 입력 후 응답만 시간 초과되는지를 구분하면 확인 범위를 줄일 수 있습니다. 같은 기기에서 일반 웹사이트도 열리지 않는다면 ChatGPT 규칙만 수정하기 전에 코어 실행 상태, 로컬 프록시 포트, 인터넷 연결부터 확인해야 합니다.
| 증상 | 우선 점검 | 확인할 위치 |
|---|---|---|
| 페이지가 바로 열리지 않음 | 코어 상태, 시스템 프록시, 모드 | 클라이언트 상태와 브라우저 프록시 설정 |
| 로그인 화면에서 반복적으로 멈춤 | 인증 요청의 규칙과 DNS | 연결 기록의 도메인, 정책 그룹, 결과 |
| 대화 전송만 시간 초과됨 | 노드 안정성, 장시간 연결, 네트워크 변경 | 같은 노드에서 다른 사이트와 재시도 결과 |
| 한 브라우저에서만 실패 | 브라우저별 프록시, 확장 기능, 캐시 | 다른 브라우저 또는 새 프로필 |
테스트 중에는 노드를 바꾸고 규칙도 고치고 TUN까지 켜는 식으로 여러 설정을 한꺼번에 변경하지 마세요. 한 번에 하나씩 바꿔야 어떤 조치가 결과를 바꿨는지 알 수 있습니다. 설정을 크게 수정하기 전에는 현재 프로필과 모드, 선택한 노드를 기록해 두면 원래 상태로 되돌리기 쉽습니다.
시스템 프록시, 모드, 선택한 노드를 확인하세요
일반 브라우저는 운영체제의 시스템 프록시 설정을 따르는 경우가 많지만, 모든 앱이 이를 따르는 것은 아닙니다. Clash 클라이언트에서 코어가 실행 중인지 확인한 다음 시스템 프록시 스위치가 켜져 있는지 살펴보세요. Windows에서는 설정의 네트워크 및 인터넷 프록시 항목, macOS에서는 네트워크 서비스의 프록시 설정을 함께 확인할 수 있습니다. 클라이언트가 시스템 프록시를 자동으로 설정하는 환경이라면 수동으로 다른 주소나 포트를 입력하지 마세요.
규칙 모드에서는 대상 도메인에 먼저 일치한 규칙이 연결에 적용됩니다. 프록시 그룹에서 노드를 선택했더라도 ChatGPT 연결이 DIRECT 규칙에 먼저 일치하면 그 연결은 선택한 노드를 거치지 않습니다. 반대로 전역 모드에서는 전체 연결이 전역 정책을 따르므로, 규칙 모드에서 기대한 도메인별 분기가 적용되지 않습니다. 클라이언트 화면의 작동 모드와 실제 활성 설정이 서로 다르지 않은지도 확인하세요.
연결 기록에서 실제 경로를 읽는 방법
ChatGPT에 접속을 시도하면서 클라이언트의 연결 또는 로그 화면을 열어 보세요. chatgpt.com뿐 아니라 로그인과 콘텐츠 전달에 사용되는 관련 호스트가 별도 연결로 표시될 수 있습니다. 연결마다 매칭된 규칙, 적용된 프록시 그룹, 연결 상태를 확인합니다. 도메인 이름 대신 IP 주소만 보인다면 해당 연결에서 도메인 기반 규칙이 기대한 대로 매칭되지 않을 수 있으므로 DNS 경로와 도메인 확인 동작도 점검하세요.
ChatGPT와 관련된 도메인 목록은 서비스 기능과 접속 흐름에 따라 달라질 수 있습니다. 특정 도메인 몇 개만 추가하면 언제나 해결된다고 가정하거나, 확인하지 않은 광범위한 키워드 규칙을 추가하지 마세요. 연결 기록에 나타난 실제 도메인을 기준으로 규칙을 검토하고, 기존 규칙 제공자나 구독 설정을 직접 수정해야 하는 경우에는 다음 업데이트에서 변경이 덮어써지는지도 확인하세요.
단계별 테스트로 실패 지점을 좁혀 보세요
아래 절차는 Windows에서 로컬 프록시 포트가 7890이라고 가정한 예시입니다. 사용 중인 클라이언트의 포트가 다르면 화면에 표시된 HTTP 또는 혼합 프록시 포트로 바꾸세요. 이 테스트는 프록시 연결 자체를 확인하기 위한 것이며, 특정 서비스의 이용 가능 여부나 모든 브라우저의 동작을 보장하지는 않습니다.
- 클라이언트에서 코어가 실행 중인지 확인하고 현재 모드를 규칙으로 설정합니다. 연결 테스트 중에는 노드 선택을 변경하지 않습니다.
- PowerShell을 열고 로컬 포트가 연결을 받고 있는지 확인합니다.
- 같은 포트를 명시해 일반 HTTPS 주소에 요청합니다. 브라우저 설정과 시스템 프록시의 영향을 분리하려는 단계입니다.
- 클라이언트 연결 기록에서 테스트 요청이 어떤 정책으로 처리됐는지 확인한 뒤, 같은 조건으로 ChatGPT 접속을 시도합니다.
Test-NetConnection 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/
TcpTestSucceeded : False라면 원격 노드보다 먼저 코어 실행 상태, 포트 번호, 수신 주소를 점검하세요. 클라이언트가 SOCKS 전용 포트를 제공한다면 위의 HTTP 프록시 예시와 구분해야 합니다.- 일반 HTTPS 요청은 성공하지만 브라우저에서 ChatGPT만 실패하면 시스템 프록시가 브라우저에 적용되는지, ChatGPT 연결이 어떤 규칙에 매칭되는지 확인하세요.
- 일반 요청과 ChatGPT 요청이 모두 시간 초과되면 다른 노드를 하나 선택해 같은 테스트를 반복합니다. 노드 변경 전후에 모드와 테스트 주소를 같게 유지하세요.
- 명시적 프록시 요청은 성공하고 한 브라우저에서만 실패한다면 다른 브라우저나 새 프로필로 비교하고, 브라우저 자체 프록시 설정과 관련 확장 기능을 확인하세요.
실패가 특정 노드에서만 반복되고 다른 노드에서는 같은 조건으로 성공한다면 노드 또는 해당 출구의 경로가 원인일 가능성이 높습니다. 여러 노드에서 똑같이 실패한다면 모드, 규칙, 로컬 DNS, 시스템 프록시처럼 공통으로 사용하는 설정을 먼저 살펴보세요. 테스트 결과와 발생 시각을 함께 기록하면 간헐적인 시간 초과를 구분하는 데 도움이 됩니다.
규칙과 DNS를 수정할 때는 실제 연결을 기준으로 하세요
연결 기록에서 ChatGPT 관련 요청이 직접 연결로 처리되는 것이 확인됐다면, 해당 규칙이 의도한 정책을 가리키는지 검토하세요. 예를 들어 활성 설정에서 실제로 존재하는 프록시 그룹 이름을 사용하고, 더 넓은 범위의 규칙보다 구체적인 예외 규칙이 먼저 검사되는지 확인할 수 있습니다. 아래는 규칙 작성 형태를 보여 주는 예시이며, 모든 ChatGPT 연결에 필요한 도메인을 완전하게 나열한 목록은 아닙니다.
rules:
- DOMAIN,chatgpt.com,프록시 선택
- DOMAIN-SUFFIX,openai.com,프록시 선택
- MATCH,DIRECT
여기서 프록시 선택은 설정의 proxy-groups에 실제로 존재하는 그룹 이름으로 바꿔야 합니다. 기존에 도메인 범위가 넓은 규칙이나 규칙 제공자가 있다면 새 규칙을 어디에 두는지가 결과에 영향을 줍니다. 규칙 목록의 맨 아래에 추가해도 앞선 규칙이 먼저 일치하면 새 규칙은 사용되지 않습니다. 구독 관리 클라이언트에서는 원본 파일을 직접 편집하기보다 지원되는 규칙 오버라이드 기능을 사용하세요.
DNS 문제를 의심할 때는 이름 확인 실패와 프록시 연결 실패를 구분해야 합니다. DNS 조회가 실패하면 도메인에 연결하기 전에 오류가 발생할 수 있고, 조회가 성공해도 잘못된 규칙이나 사용할 수 없는 출구 때문에 요청이 시간 초과될 수 있습니다. DNS 설정을 한 번에 여러 곳에서 바꾸면 문제가 재현되더라도 원인을 찾기 어려워집니다. 현재 사용 중인 클라이언트와 코어가 제공하는 DNS 로그를 확인하고, 캐시를 지운 뒤에도 동일한 결과인지 비교하세요.
TUN은 마지막에 시험하고 결과를 비교하세요
시스템 프록시는 해당 설정을 따르는 앱의 요청을 처리하지만 일부 프로그램은 자체 네트워크 연결을 사용해 시스템 프록시를 무시할 수 있습니다. 이런 앱에서만 연결이 실패한다면 TUN 모드가 보완책이 될 수 있습니다. TUN은 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 처리하므로 시스템 프록시와 범위가 다릅니다. 관리자 권한, 가상 어댑터, 라우팅, DNS 동작에도 영향을 줄 수 있어 처음부터 켜기보다는 일반 프록시 경로를 확인한 뒤 시험하세요.
TUN을 켜기 전에는 현재 설정을 기록하고 클라이언트에서 지원 여부와 권한 상태를 확인합니다. 활성화한 뒤에는 브라우저가 여전히 시스템 프록시만 사용하는 구성인지, 중복 VPN이나 다른 가상 네트워크 도구가 실행 중인지 살펴보세요. TUN을 켠 뒤 연결이 나빠졌다면 두 경로를 동시에 바꾸기보다 TUN을 끄고 이전 조건에서 같은 요청이 성공하는지 비교합니다.
노드 품질도 한 번의 지연 시간 숫자만으로 판단하지 마세요. 연결 기록에 재시도나 반복적인 시간 초과가 있는지 살펴보고, 같은 노드로 일반 HTTPS 사이트와 ChatGPT를 각각 테스트하세요. 다른 네트워크에 연결된 기기에서 같은 노드와 설정을 비교하면 로컬 네트워크 문제인지 노드 경로 문제인지 더 쉽게 구분할 수 있습니다. 노드가 바뀌면 출구 주소와 원격 경로도 달라질 수 있으므로 그 결과만으로 규칙이 수정됐다고 볼 수는 없습니다.
서비스 접속 가능성은 지역, 계정, 네트워크 환경, 서비스 정책에 따라 달라질 수 있습니다. 네트워크 연결이 정상인데 계정이나 지역 관련 안내가 표시된다면 Clash 규칙만 계속 바꾸지 말고 해당 서비스의 공식 안내와 적용 가능한 이용 조건을 확인하세요. 원인을 찾은 뒤에는 임시 테스트 규칙과 불필요한 TUN 설정을 정리하고, 평소 사용하는 모드와 규칙으로 되돌려 안정성을 확인하는 것이 좋습니다.