설정 실전 2026-08-27 약 14분 소요

Claude 접속 안 됨? Clash 타임아웃과 연결 실패 해결법

Claude가 Clash 환경에서 작동하지 않는다면 프록시 모드 오류, 규칙 누락, DNS 문제 또는 불안정한 노드가 원인일 수 있습니다. 단계별 점검으로 설정 문제와 서비스 제공 업체 문제를 구분해 보세요.

Claude 접속 실패 증상부터 구분하기

Clash를 켠 뒤 Claude 웹 화면이 계속 로딩되거나 “연결 시간 초과”, “네트워크 오류”, “응답을 불러오지 못했습니다”와 같은 메시지가 나타날 수 있습니다. 모바일 앱에서는 로그인 화면으로 돌아가거나 대화 목록만 비어 보이고, API를 사용하는 도구에서는 ETIMEDOUT, ECONNRESET, TLS 핸드셰이크 실패가 기록되기도 합니다. 이 증상만으로 노드가 완전히 죽었다고 단정하면 안 됩니다. 웹 페이지 요청은 통과하지만 스트리밍 응답이나 인증 요청만 막히는 경우도 있기 때문입니다.

먼저 Clash를 종료했을 때 Claude가 정상적으로 열리는지 확인하세요. Clash를 끄면 바로 접속되고 다시 켰을 때만 실패한다면 계정이나 서비스 장애보다 프록시 모드, 규칙, DNS, 노드 품질을 우선 점검해야 합니다. 반대로 여러 네트워크와 여러 클라이언트에서 동시에 실패한다면 서비스 제공 업체의 구독 만료나 일시적인 서비스 장애일 가능성이 높습니다.

증상	우선 의심할 원인	첫 번째 확인 지점
페이지 자체가 열리지 않음	노드 연결, 규칙 누락, DNS	Clash 연결 상태와 로그
로그인은 되지만 대화가 로드되지 않음	스트리밍·API 관련 도메인 누락	요청 도메인의 정책 그룹
응답 도중 멈추거나 재연결됨	노드 지연, 패킷 손실, WebSocket 처리	다른 노드의 반복 테스트
모든 노드에서 동일하게 실패	구독 만료, 서비스 측 제한, 클라이언트 오류	구독 갱신과 다른 네트워크

프록시 모드와 시스템 적용 상태 확인

가장 흔한 원인은 Clash에서 노드를 선택했지만 실제 애플리케이션 트래픽에는 프록시가 적용되지 않은 경우입니다. 일반 데스크톱 앱에서는 먼저 프로필을 활성화한 다음, 정책 그룹에서 사용할 노드를 선택하고, 마지막으로 시스템 프록시 또는 TUN을 켜야 합니다. 프로필을 가져오기만 하고 활성화하지 않았다면 화면에 노드 목록이 보여도 실제 연결에는 이전 설정이 사용될 수 있습니다.

Clash Verge, Clash Verge Rev 또는 mihomo 기반 클라이언트에서 현재 프로필이 활성 상태인지 확인합니다.
정책 그룹을 열고 자동 선택 그룹 대신 특정 노드를 임시로 지정합니다. 처음부터 자동 선택을 사용하면 어떤 노드가 실패했는지 판단하기 어렵습니다.
모드 메뉴에서 규칙 모드를 선택한 뒤, 테스트 목적이라면 잠시 전역 모드로 바꿔 차이를 비교합니다.
Windows와 macOS는 시스템 프록시가 켜져 있는지 확인하고, Android와 iOS는 VPN 연결 권한이 유지되는지 확인합니다.
브라우저에서 새 개인 창을 열고 다시 접속합니다. 기존 세션의 쿠키나 확장 프로그램이 오류 판단을 방해할 수 있습니다.

전역 모드에서는 접속되지만 규칙 모드에서만 실패한다면 노드 자체보다 규칙 문제가 유력합니다. 두 모드 모두 실패하면 선택한 노드, DNS, TUN 스택 또는 서비스 제공 업체 상태를 이어서 확인하세요. 전역 모드는 원인 분리를 위한 임시 테스트로만 사용하고, 평소에는 필요한 트래픽만 프록시로 보내는 규칙 모드가 관리하기 쉽습니다.

TUN과 시스템 프록시를 동시에 무작정 겹치지 않기

TUN과 시스템 프록시를 함께 사용할 수 있는지는 클라이언트와 운영체제에 따라 다릅니다. 두 경로가 중복되면 요청이 두 번 처리되거나 로컬 예외가 꼬일 수 있습니다. 테스트할 때는 하나만 켜고, 변경할 때마다 브라우저를 완전히 종료한 뒤 다시 실행하세요.

규칙 누락과 DNS 문제를 함께 점검하기

Claude 접속은 메인 웹 주소 하나만 통과시키면 끝나지 않습니다. 로그인, 정적 리소스, 인증, API, 실시간 응답에 사용되는 관련 요청이 서로 다른 호스트로 분리될 수 있습니다. 특정 화면은 열리는데 로그인 완료 후 멈추거나 답변 생성 버튼만 실패한다면, 요청이 다른 도메인으로 이동했는데 규칙이 그 트래픽을 DIRECT로 보낸 상황을 의심해야 합니다.

Clash의 연결 로그를 열어 실패 시각에 생성된 요청을 확인하세요. 요청의 목적지, 포트, 매칭된 규칙, 최종策略 그룹을 함께 봐야 합니다. 대상이 프록시 그룹으로 매칭되어야 하는데 DIRECT로 표시되면 프로필의 규칙 순서를 수정합니다. 반대로 모든 요청이 프록시로 가는데도 연결이 실패한다면 노드나 DNS가 원인일 수 있습니다.

서비스 제공 업체가 관리하는 AI 서비스 규칙 세트가 있다면 먼저 업데이트하고, 현재 mihomo 커널에서 지원되는 형식인지 확인합니다.
직접 작성할 때는 공식 서비스 문서에서 현재 사용하는 도메인 목록을 확인한 뒤 DOMAIN-SUFFIX 또는 관리형 규칙 세트에 추가합니다.
짧은 DOMAIN-KEYWORD를 남발하지 마세요. 관련 없는 도메인까지 프록시로 보내 DNS와 연결 지연이 늘어날 수 있습니다.
마지막 MATCH 규칙이 DIRECT라면 누락된 해외 요청이 모두 직결될 수 있으므로, 테스트 프로필에서는 기본 출구를 프록시로 두고 범위를 확인합니다.

DNS 오류는 로그에 “도메인을 찾을 수 없음”, “서버를 찾을 수 없음”처럼 나타나거나, 같은 노드가 다른 기기에서는 작동하는데 한 기기에서만 실패하는 형태로 드러납니다. mihomo의 DNS 설정에서 enable: true인지 확인하고, enhanced-mode: fake-ip를 사용할 때는 가상 주소 대역과 시스템 예외 목록이 충돌하지 않는지 살펴보세요. 노드 서버 이름을 해석하는 경로에는 proxy-server-nameserver를 활용해 프록시 연결 자체가 로컬 DNS 오염의 영향을 받지 않게 구성할 수 있습니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.example.invalid/dns-query
  proxy-server-nameserver:
    - 223.5.5.5

위 코드는 구조를 설명하기 위한 예시입니다. 실제 업스트림 주소는 사용하는 환경과 서비스 제공 업체의 안내에 맞춰 바꾸세요. 설정을 수정한 뒤에는 DNS 캐시를 지우고 클라이언트를 재시작해야 이전의 잘못된 응답이 남지 않습니다.

노드 품질과 연결 시간 초과 측정하기

규칙과 DNS가 정상인데도 타임아웃이 발생한다면 노드 품질을 분리해서 측정해야 합니다. Clash의 지연 테스트 숫자는 짧은 HTTP 요청의 왕복 시간일 뿐이며, 실제 Claude 응답 속도나 스트리밍 안정성을 완전히 보장하지 않습니다. 150ms로 표시되는 노드도 혼잡 시간대에 패킷 손실이 심하면 긴 응답을 끝까지 유지하지 못할 수 있습니다.

정책 그룹에서 서로 다른 지역의 노드 세 개를 선택해 각각 지연 테스트를 실행합니다.
가장 빠른 하나만 고르지 말고 3~5분 간격으로 재검사해 지연 변동을 기록합니다.
각 노드에서 Claude 페이지 접속, 로그인, 짧은 대화 전송, 긴 응답 수신을 순서대로 테스트합니다.
연결 로그에서 TCP 연결 실패인지 TLS 실패인지, 또는 응답 중 연결 종료인지 구분합니다.
특정 노드에서만 문제가 반복되면 해당 노드를 제외하고 자동 선택 그룹의 테스트 URL과 허용 지연값을 조정합니다.

여러 노드에서 초반 페이지는 열리지만 응답 생성 중 끊긴다면 서비스 제공 업체의 출구 품질이나 장시간 연결 제한을 의심할 수 있습니다. 이때 클라이언트의 연결 재사용 옵션, TUN 스택, MTU를 한꺼번에 바꾸지 말고 하나씩 비교하세요. 특히 MTU는 네트워크마다 최적값이 다르므로 근거 없이 크게 낮추면 속도와 안정성이 오히려 떨어질 수 있습니다.

로그에서 확인할 핵심 문구

dial timeout은 노드까지 연결하는 단계의 지연, i/o timeout은 응답 대기 시간 초과, TLS 관련 오류는 서버 이름·시간·중간 네트워크 문제를 뜻할 수 있습니다. 오류 문구와 발생한 목적지, 사용한 노드 이름을 함께 기록하면 서비스 제공 업체에 문의할 때 재현 정보로 활용할 수 있습니다.

클라이언트 오류와 서비스 제공 업체 문제 구분

같은 구독을 두 개의 Clash 클라이언트에서 비교하면 원인 범위를 빠르게 줄일 수 있습니다. 예를 들어 Clash Verge Rev에서는 정상인데 다른 클라이언트에서만 실패한다면 커널 버전, 프로필 호환성, TUN 권한을 확인해야 합니다. 반대로 Windows와 Android에서 같은 노드가 동시에 실패하고 구독 갱신도 불안정하다면 클라이언트보다 서비스 제공 업체의 노드 상태나 계정 제한이 우선입니다.

클라이언트 문제 가능성: 특정 기기에서만 실패, 권한 변경 직후 발생, 프로필 파싱 오류, TUN을 켤 때만 실패.
프로필 문제 가능성: 업데이트 후 정책 그룹이 사라짐, 규칙 파일 다운로드 실패, 마지막 규칙이 예상과 다르게 변경됨.
노드 문제 가능성: 특정 지역 노드만 실패, 지연과 패킷 손실이 반복됨, 다른 노드에서는 즉시 정상.
서비스 측 문제 가능성: 모든 기기와 노드에서 동일한 실패, 구독 사용량 초과, 구독 주소 만료, 제공 업체 공지와 시간대가 일치.

문제가 해결된 뒤에는 전역 모드를 계속 유지하지 말고 규칙 모드로 돌아오세요. 사용하지 않는 노드는 정책 그룹에서 제거하고, 프로필 자동 업데이트 주기를 지나치게 짧게 설정하지 않는 것이 좋습니다. 설정 파일을 수정하기 전에는 현재 프로필을 별도 복사해 두면 잘못된 규칙을 쉽게 되돌릴 수 있습니다.

재발 방지를 위한 최종 체크리스트

Claude 연결 문제는 한 가지 설정만 바꾸어 해결하기보다, “프록시가 실제로 적용되었는가 → 요청이 올바른 정책으로 갔는가 → DNS가 정상 해석되었는가 → 노드가 장시간 연결을 유지하는가”의 순서로 확인하는 것이 가장 빠릅니다. 각 단계에서 정상 여부를 기록하면 같은 오류가 다시 발생해도 처음부터 모든 설정을 추측할 필요가 없습니다.

프로필을 활성화하고 정책 그룹에 실제 사용 노드를 지정했는가?
시스템 프록시 또는 TUN 중 필요한 방식이 정상적으로 켜져 있는가?
연결 로그에서 Claude 관련 요청이 DIRECT가 아닌 프록시 그룹으로 매칭되는가?
DNS 모듈이 활성화되어 있고, fake-ip 대역이나 DNS 예외가 충돌하지 않는가?
최소 세 개의 노드에서 페이지와 긴 응답을 각각 테스트했는가?
다른 기기와 네트워크에서도 동일한 오류가 재현되는가?

가장 빠른 판단 순서

전역 모드에서 특정 노드로 접속을 시험하고, 성공하면 규칙 로그에서 누락된 요청을 찾습니다. 전역 모드에서도 실패하면 다른 노드와 DNS를 비교하고, 모든 기기에서 실패할 때만 구독 만료나 서비스 제공 업체 장애를 문의하세요.

Clash 설정과 클라이언트 선택 이어가기

사용 중인 클라이언트의 메뉴가 다르거나 TUN·DNS 설정을 처음 조정한다면 플랫폼별 설치와 기본 설정 순서를 먼저 확인하는 편이 안전합니다. 현재 클라이언트와 구독 프로필을 정리한 뒤 필요한 항목만 단계적으로 변경하세요.

다운로드 보기 설정 튜토리얼

자주 나타나는 오류와 원인별 해결법

증상	가능한 원인	확인할 항목
로그인 명령이 즉시 연결 거부	Clash가 꺼져 있거나 포트가 다름	mixed-port, HTTP 포트, 로컬 리스닝 상태
브라우저 인증은 끝났지만 CLI가 대기	콜백 주소가 프록시나 보안 프로그램에 의해 차단됨	localhost를 `NO_PROXY`에 포함했는지 확인
TLS handshake timeout	노드 품질 저하, 잘못된 규칙, MTU 문제	Clash 로그, 다른 노드, TUN 사용 여부
인증 성공 후 요청만 실패	API 요청이 다른 호스트로 이동하거나 규칙에서 DIRECT 처리됨	요청 도메인의规则匹配 결과와 프록시 그룹
명령을 찾을 수 없음	CLI 설치 경로가 PATH에 없음	`codex --help`, 운영체제 PATH, 설치 방식
인증 정보가 반복해서 사라짐	권한 문제, 임시 컨테이너, 자격 증명 저장 실패	설정 디렉터리 쓰기 권한과 실행 환경

로그인 콜백이 멈추는 경우에는 NO_PROXY가 지나치게 넓게 설정되지 않았는지 확인하세요. localhost와 127.0.0.1은 로컬 콜백을 위해 직접 연결하는 것이 일반적이지만, 외부 인증 서버 도메인을 무심코 NO_PROXY에 넣으면 브라우저 인증 페이지와 CLI의 인증 요청이 서로 다른 경로로 나갈 수 있습니다.

반대로 TUN 모드에서 localhost까지 가상 인터페이스로 보내면 콜백 서버가 정상적으로 응답하지 않을 수 있습니다. 이런 환경에서는 DNS 하이재킹과 자동 라우팅을 켜더라도 로컬 주소 예외를 유지하세요. TUN을 켠 뒤 문제가 시작됐다면 TUN을 끄고 환경 변수 방식으로 재시험하면 원인을 빠르게 분리할 수 있습니다.

프록시 오류와 인증 오류를 구분하세요

“connection refused”, “timeout”, “TLS handshake”는 대체로 네트워크 경로 문제이고, 인증 만료·권한 부족·잘못된 계정은 서버가 반환하는 인증 단계의 오류입니다. 전자는 Clash 로그와 포트를 먼저 보고, 후자는 Codex CLI의 로그아웃 후 재로그인과 계정 권한을 확인해야 합니다.

TUN과 DNS를 사용할 때의 추가 점검

Codex CLI가 실행하는 셸 명령이나 패키지 도구까지 같은 네트워크 정책으로 처리해야 한다면 TUN 모드가 편리할 수 있습니다. 다만 TUN은 단순히 브라우저를 프록시로 바꾸는 기능이 아니라 시스템 라우팅과 DNS 흐름을 변경하는 기능입니다. Windows에서는 서비스 모드와 관리자 권한이 필요할 수 있고, macOS에서는 네트워크 확장 또는 VPN 구성 허용이 요구될 수 있습니다.

mihomo 기반 클라이언트에서는 auto-route, auto-detect-interface, dns-hijack 설정이 서로 맞물립니다. 자동 라우팅이 꺼져 있으면 TUN 인터페이스가 만들어져도 일부 트래픽이 기존 네트워크 카드로 빠질 수 있습니다. DNS 하이재킹이 빠지면 도메인 조회는 운영체제 DNS로 남아 규칙 매칭이 불안정해질 수 있습니다. fake-ip을 사용하는 경우 198.18.0.1/16과 같은 가상 대역이 로컬 네트워크 규칙에 의해 차단되지 않는지도 확인하세요.

Clash 로그에서 DNS 요청이 기록되는지 확인합니다.
nslookup 또는 dig 결과가 매번 바뀌는지, 특정 잘못된 주소가 반복되는지 비교합니다.
사내 도메인과 로컬 프린터 주소는 NO_PROXY 또는 DIRECT 규칙으로 분리합니다.
패키지 설치 명령이 실패하면 Codex 자체가 아니라 패키지 저장소의 인증서, 별도 프록시 설정, 저장소 정책을 확인합니다.

터미널 명령 실행을 허용할 때는 네트워크가 안정적이라는 이유만으로 모든 명령을 자동 승인하지 마세요. Codex CLI가 파일을 수정하거나 외부 패키지를 설치하도록 설정되어 있다면 프로젝트 디렉터리, 셸 권한, 환경 변수에 저장된 비밀 정보까지 함께 고려해야 합니다. 먼저 읽기 작업으로 검증하고, 변경 작업은 명령별로 확인하는 것이 안전합니다.

FAQ: Codex CLI와 Clash 연결 문제

시스템 프록시를 켰는데도 Codex CLI가 직접 연결되는 이유는 무엇인가요?

터미널 프로그램이나 내부 HTTP 라이브러리가 운영체제의 시스템 프록시를 읽지 않을 수 있습니다. 현재 셸에 HTTP_PROXY와 HTTPS_PROXY를 직접 지정한 뒤 다시 실행하세요. 그래도 로그가 보이지 않으면 TUN 모드로 비교 테스트를 진행해 프로세스가 프록시 변수를 무시하는지 확인할 수 있습니다.

HTTP_PROXY와 HTTPS_PROXY에 서로 다른 포트를 넣어야 하나요?

Clash의 mixed 포트를 사용한다면 두 변수에 같은 HTTP 주소를 넣어도 됩니다. 다만 실제 클라이언트에서 HTTP와 SOCKS 포트가 분리되어 있다면 HTTPS 요청에 SOCKS 포트를 HTTP 주소로 입력하지 않도록 주의하세요. 포트 형식과 프로토콜이 맞지 않으면 연결 거부 또는 TLS 오류가 발생합니다.

Codex 로그인 후에는 환경 변수를 삭제해도 되나요?

로그인 정보가 안전하게 저장되고 이후 요청이 직접 연결로도 허용되는 환경이라면 가능하지만, 인증 후 API 요청도 프록시가 필요한 네트워크라면 환경 변수를 계속 유지해야 합니다. 테스트할 때는 변수를 삭제한 새 셸에서 간단한 요청을 실행해 인증 경로와 실제 작업 경로가 모두 정상인지 구분하세요.

노드를 바꾸면 Codex CLI 인증을 다시 해야 하나요?

일반적으로 노드 변경만으로 저장된 인증 정보가 사라지지는 않습니다. 그러나 출구 지역이나 IP가 바뀌면서 보안 확인이 추가되거나, 이전 연결이 만료되어 재인증이 요구될 수 있습니다. 짧은 시간에 여러 지역의 노드를 반복해서 바꾸기보다 안정적인 하나의 그룹을 선택하고 Clash 로그에서 연결 상태를 확인하세요.

다음 단계: Clash 설정과 Codex 실행 환경 정리

Codex CLI 연결 문제는 대부분 클라이언트 자체보다 로컬 포트, 셸 환경 변수, DNS 경로, 규칙 순서 중 하나에서 발생합니다. 먼저 mixed 포트와 전역 연결을 이용해 기본 경로를 검증한 뒤, 규칙 모드와 TUN 모드로 범위를 좁히면 불필요한 설정 변경을 줄일 수 있습니다. 설치 파일과 클라이언트 선택이 아직 정해지지 않았다면 다운로드 센터에서 플랫폼에 맞는 mihomo 기반 클라이언트를 확인하고, 적용 후에는 단계별 튜토리얼에 따라 프로필과 프록시 모드를 설정하세요.

전방위 다운로드 설정 튜토리얼