이 글의 목차
ChatGPT나 Claude 홈 화면은 열리지만 로그인이나 메시지 전송이 실패한다면 홈 화면을 다시 여는 것으로 원인을 알 수는 없습니다. 실패한 동작의 상태 코드와 Clash 기록을 대조해 요청이 프록시에 도착하지 않았는지, 잘못된 접속 경로를 사용했는지, 서비스에 도착했지만 거부됐는지 구분하세요. 테스트 중에는 노드를 고정한 채 로그인 세션과 지속적인 응답을 각각 확인해 접속 경로 변경이 판단에 영향을 주지 않도록 합니다.
시간 초과, 403, 응답 중단이 의미하는 것
오류 원문, 발생 시간, 직전 동작을 기록하고 로그인 실패인지, 페이지 구성 요소가 비어 있는지, 응답이 중단됐는지 구분하세요. 모두 “연결 안 됨”으로 기록하지 마세요. 서로 다른 요청에서 발생한 현상일 수 있습니다.
오류 메시지와 확인할 위치
| 표시된 현상 | 우선 판단 |
|---|---|
| 페이지 틀은 나타나지만 아이콘, 버튼 또는 로그인 구성 요소가 비어 있음 | 정적 리소스 도메인이 다른 규칙 또는 출구를 사용할 수 있음 |
| ERR_CONNECTION_TIMED_OUT / 요청 시간 초과 | 네트워크 경로, 노드 또는 장기 연결 실패 |
| 401 / Unauthorized | 로그인 상태, 토큰 또는 API 자격 증명 |
| 403 / Access Denied | 서비스 정책, 계정 상태 또는 요청 거부 |
| 429 / Too Many Requests | 빈도 또는 할당량 제한이며 노드 지연 문제가 아님 |
| 500 / 502 / 503 | 서버 또는 상위 서비스의 일시적인 장애이므로 공식 상태부터 확인 |
| 응답 생성이 중간에 멈춤 | 스트리밍 연결, 노드 전환 또는 네트워크 흔들림 |
페이지 틀은 보이지만 내용이 로드되지 않는다면 스크립트, 이미지, 로그인 구성 요소의 요청을 확인하세요. 이 리소스들은 서로 다른 정적 리소스 도메인에서 올 수 있습니다. 로그인 리디렉션, 파일 업로드, 모델 스트리밍 응답도 별도 요청을 보냅니다. Connections에서 리소스와 모델 요청을 하나씩 확인해 같은 안정적인 접속 경로를 쓰는지 점검하세요. 다른 웹페이지를 여는 것으로 이 테스트를 대신하지 마세요.
노드를 고정하고 실패한 요청의 출구 확인
재현 가능한 시험 만들기
Proxies에서 노드 하나 고정
시험 중 출구가 바뀌지 않도록 잠시 url-test 또는 fallback을 사용하지 않습니다.
Rule 모드 유지
Connections를 열고 실패한 동작에 해당하는 도메인과 규칙을 관찰할 준비를 합니다.
동작 하나만 반복
예를 들어 로그인을 클릭하거나 같은 짧은 메시지를 보내거나 같은 작은 파일을 업로드합니다.
페이지 상태와 Clash 결과 저장
HTTP 상태, 연결 출구, 소요 시간, 로그 오류를 기록합니다.
실패 동작을 Connections에서 전혀 찾을 수 없다면 브라우저 또는 데스크톱 앱이 현재 Clash를 거치지 않았을 수 있습니다. 기록이 나타나지만 DIRECT에 맞으면 규칙을 확인하고 고정 노드까지 갔는데 timeout이 발생할 때만 노드나 네트워크로 비교하세요.
로그인 반복: 브라우저 세션과 인증 요청 확인
로그인 순환은 계정을 입력한 뒤 다시 로그인 페이지로 돌아가거나 인증 코드를 완료해도 대화로 들어가지 못하는 형태가 흔합니다. 이때 같은 브라우저의 시크릿 창에서 다시 시험해 만료된 세션과 확장 기능 간섭을 배제하세요. 처음부터 모든 사이트 데이터를 삭제하면 다른 계정에서도 함께 로그아웃됩니다.
로그인 클릭 후 요청을 관찰하세요. 인증 리디렉션이 Clash에 들어오지 않으면 브라우저 프록시를 처리합니다. 요청이 들어온 뒤 401 또는 403을 반환하면 네트워크가 서비스에 도달한 것이므로 계정, 로그인 방식, 서비스 안내를 계속 확인하세요. 지역이나 출구를 자주 바꾸면 한 번의 로그인이 여러 세션 환경을 거칠 수 있으므로 시험 중에는 고정 노드를 유지해야 합니다.
403 Access Denied: 계정, 지역, 서비스 제한
명확한 403이나 Access Denied는 보통 요청이 웹사이트에 도착했지만 거부되었다는 뜻입니다. 페이지에 나온 이유, 계정 상태, 지역 제한, 서비스 지원 범위, 현재 출구가 서비스 약관에 맞는지 확인하세요. 이런 거부는 DNS 시간 초과나 열리지 않은 포트와 원인이 다릅니다.
Global 모드는 특정 규칙이 요청을 잘못된 출구로 보냈는지 판단하는 용도로만 쓸 수 있으며 서버의 거부를 네트워크 성공으로 바꾸지는 못합니다. Rule과 Global이 같은 고정 노드에서 동일한 403을 반환한다면 Clash 조정을 멈추고 계정이나 서비스 정책을 처리하세요.
긴 응답이 끊기면 노드와 접속 네트워크 비교
모델 응답은 데이터를 계속 반환하므로 지연 측정에 성공해도 수십 초 동안 안정적으로 연결을 유지할 수 있다는 뜻은 아닙니다. 테스트할 때 정책 그룹을 select(수동 선택)로 바꾸고 노드를 고정한 뒤 반복 가능한 긴 질문을 사용해 응답이 끊길 때 Connections의 종료 이유를 확인하세요.
같은 고정 노드를 가정용 네트워크와 휴대전화 핫스폿에서 각각 한 번 시험하세요. 한 네트워크에서만 중단되면 해당 네트워크와 DNS를 중점적으로 확인하고 두 네트워크에서 비슷한 위치에 중단되면 다른 프로토콜 또는 노드로 비교합니다. 한 번 성공했다고 결론 내리지 말고 같은 요청을 적어도 두세 번 반복하세요.
웹사이트는 정상이지만 데스크톱 앱이나 API가 접속되지 않는다
브라우저는 대체로 Windows 또는 macOS 시스템 프록시를 사용하지만 터미널의 curl, SDK와 일부 데스크톱 앱은 자체 네트워크 설정을 사용할 수 있습니다. 같은 API 요청의 새 기록이 Connections에 없다면 바로 노드를 바꾸기보다 앱이 현재 프록시를 사용하는지 먼저 확인하세요.
명령줄 도구는 자체 문서에 따라 HTTP_PROXY, HTTPS_PROXY를 설정할 수 있습니다. 시스템 프록시를 읽지 않는 여러 앱을 통합해서 제어해야 할 때만 TUN을 고려하세요. API가 401을 반환했다면 요청이 서버에 도달한 것이므로 프록시 범위를 계속 넓히지 말고 API key와 요청 형식을 확인해야 합니다.
CLASH_PORT=7890
export HTTP_PROXY="http://127.0.0.1:${CLASH_PORT}"
export HTTPS_PROXY="http://127.0.0.1:${CLASH_PORT}"
export NO_PROXY="localhost,127.0.0.1,::1"
curl -I https://example.com$CLASH_PORT = 7890
$env:HTTP_PROXY = "http://127.0.0.1:$CLASH_PORT"
$env:HTTPS_PROXY = "http://127.0.0.1:$CLASH_PORT"
$env:NO_PROXY = "localhost,127.0.0.1,::1"
curl.exe -I https://example.com전체 응답을 받은 뒤 자동 노드 선택 복원
고정 노드와 Rule 모드로 돌아가 한 번 로그인하고 짧은 메시지를 하나 보내세요. 원래 문제가 긴 응답의 중단이었다면 같은 긴 요청도 다시 실행해야 합니다. Connections에 관련 요청이 나타나고 페이지에 기존 오류가 더 이상 표시되지 않으며 응답도 끝까지 완료되어야 합니다.
짧은 메시지와 원래 실패했던 요청이 모두 끝까지 완료된 뒤 url-test 또는 fallback을 복원하세요. 자동 그룹을 복원한 후 문제가 다시 발생하면 비교 조건이 명확합니다. 계정과 규칙은 그대로이고 접속 경로 선택만 바뀐 것입니다.