이 글의 목차
페이지의 오류로 이번에 확인할 계층을 판단하세요
ChatGPT 또는 Claude가 열리지 않으면 페이지의 오류 문구를 그대로 기록하세요. 계속 로딩되는 현상, ERR_TIMED_OUT, 403 Access Denied는 서로 다른 장애입니다. 401, 429, 5xx도 각각 인증, 빈도 제한, 서버 이상을 가리킵니다. "사용 불가"라고만 적으면 이후 모든 단계를 추측해야 합니다.
페이지 결과를 먼저 이렇게 구분하세요
| 표시된 현상 | 우선 판단 |
|---|---|
| 페이지 틀은 나타나지만 아이콘, 버튼 또는 로그인 구성 요소가 비어 있음 | 정적 리소스 도메인이 다른 규칙 또는 출구를 사용할 수 있음 |
| 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을 반환하면 네트워크가 서비스에 도달한 것이므로 계정, 로그인 방식, 서비스 안내를 계속 확인하세요. 지역이나 출구를 자주 바꾸면 한 번의 로그인이 여러 세션 환경을 거칠 수 있으므로 시험 중에는 고정 노드를 유지해야 합니다.
로그인 문제에서 남길 정보
- 순환이 발생한 정확한 페이지와 버튼
- 시크릿 창에서도 같은 결과인지
- 실패 요청이 401, 403 또는 timeout 중 무엇을 반환했는지
- 로그인 전후에 같은 고정 출구를 계속 사용했는지
Access Denied는 프록시 계층을 하나 더 추가한다고 해결되지 않습니다
명확한 403 또는 Access Denied는 보통 요청이 웹사이트에 도달했지만 거부되었다는 뜻입니다. 페이지에 표시된 원인, 계정 상태, 지역 제한, 서비스 지원 범위, 현재 출구가 서비스 약관에 맞는지 확인하세요. DNS 시간 초과나 닫힌 포트와는 다른 계층의 문제입니다.
Global 모드는 특정 규칙이 요청을 잘못된 출구로 보냈는지 판단하는 용도로만 쓸 수 있으며 서버의 거부를 네트워크 성공으로 바꾸지는 못합니다. Rule과 Global이 같은 고정 노드에서 동일한 403을 반환한다면 Clash 조정을 멈추고 계정이나 서비스 정책을 처리하세요.
짧은 웹 요청은 정상인데 긴 응답이 중단되면 연결 지속성을 시험하세요
모델 응답은 계속 반환되는 데이터 스트림입니다. 노드가 지연 시간 탐지를 한 번 완료해도 수십 초 연결을 안정적으로 유지한다는 뜻은 아닙니다. 조금 길지만 반복 가능한 질문으로 시험하고 중단될 때 Connections의 종료 이유를 확인하세요. 응답 도중 다른 출구로 바뀌지 않도록 자동 전환도 끕니다.
같은 고정 노드를 가정용 네트워크와 휴대전화 핫스폿에서 각각 한 번 시험하세요. 한 네트워크에서만 중단되면 해당 네트워크와 DNS를 중점적으로 확인하고 두 네트워크에서 비슷한 위치에 중단되면 다른 프로토콜 또는 노드로 비교합니다. 한 번 성공했다고 결론 내리지 말고 같은 요청을 적어도 두세 번 반복하세요.
응답 중단 시 timeout 발생
다른 고정 노드와 네트워크를 비교해 노드 출구와 로컬 네트워크 중 원인을 찾으세요.
중단 순간 정책 그룹이 자동으로 노드를 바꿈
진단 중에는 select로 출구를 고정하고 안정된 뒤 상태 검사를 조정하세요.
페이지에 429 표시
계정 할당량과 빈도 안내를 확인하세요. 속도 측정을 계속해도 제한은 사라지지 않습니다.
모든 사용자에게 동시에 5xx 발생
공식 서비스 상태를 확인하고 상위 서비스가 복구된 뒤 다시 시험하세요.
웹은 되지만 데스크톱 앱 또는 API가 안 되면 프로세스가 시스템 프록시를 읽는지 확인하세요
브라우저는 보통 Windows 또는 macOS 시스템 프록시를 따르지만 터미널의 curl, SDK, 일부 데스크톱 앱은 자체 네트워크 설정을 사용할 수 있습니다. 같은 API 요청을 실행했는데 Connections에 기록이 전혀 없다면 아직 Clash에 들어오지 않은 것이므로 노드를 바꿔도 의미가 없습니다.
명령줄 도구는 자체 문서에 따라 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에 해당 작업과 관련된 요청이 나타나고 페이지가 기존 오류를 더 이상 반환하지 않으며 응답도 끝까지 완료되어야 합니다.
계속 실패한다면 현상에 따라 처리하세요. 연결 기록이 없으면 제어 방식을, DIRECT면 규칙을 확인합니다. timeout이면 노드와 네트워크를 비교하고 401, 403 또는 429가 반환되면 서버 결과에 따라 진단하세요.
짧은 메시지가 끝까지 반환된 뒤 url-test 또는 fallback을 복원하세요. 자동 그룹 복원 후 문제가 다시 나타나면 비교 기준이 명확합니다. 계정과 규칙은 바뀌지 않았고 출구 선택만 바뀐 것입니다.