증상 — 브라우저는 되는데 CLI만 끊기는 패턴
첫 단계에서 흔한 재현은 다음과 같습니다. 웹 UI에서는 세션이 유지되는데 Claude Code가 api.anthropic.com 대역으로 붙을 때만 읽기 시간이 초과된다. 혹은 OAuth·조직 정책에 따라 브라우저로 열리는 인증 페이지는 국내 직통이 빠른데, 토큰을 주고받는 백엔드 호출은 해외 회선이 필요해 분류 규칙이 어긋나며 스트림이 중간에 끊긴다. 또 다른 패턴은 터미널 프로세스가 HTTPS_PROXY를 존중하지 않아 사실상 DIRECT만 시도하는 경우로, 이때는 시스템 프록시를 켠다고 해서 증상이 거의 변하지 않습니다. 마지막으로 DNS가 한쪽은 공유기 캐시, 다른 쪽은 Secure DNS, 또 다른 쪽은 코어의 FakeIP로 갈려 도메인 문자열은 같은데 연결 패널에 찍히는 대상 이름이 달라져 보이는 상황도 CLI에서 두드러집니다.
HTTP/3(QUIC)를 브라우저가 우선하는 환경에서는 UDP가 규칙 밖으로 새어 나가 지연이 들쭉날쭉해 보일 수 있습니다. 이때 TUN이 꺼져 있거나 UDP 행이 DIRECT로 빠지면 체감 타임아웃이 커집니다. 활성화 절차는 Clash Verge Rev TUN 가이드를 그대로 밟되, 스택 선택은 gvisor·system 비교 글을 참고해 자신의 OS·보안 제품과 충돌이 적은 쪽을 고르세요.
왜 터미널은 TUN이 기본 답에 가깝나
데스크톱 앱과 달리 CLI는 Go·Node·Rust 런타임이 각자 TLS 스택을 들고 있고, macOS Keychain이나 Windows WPAD를 오해하거나 아예 무시하는 경우가 있습니다. 터미널 프록시 환경 변수를 매 세션마다 맞추는 방식은 재현은 되지만 팀 단위로 공유하기 어렵고, IDE가 내부적으로 띄운 서브셸과 사용자가 연 셸이 서로 다른 프로파일을 읽으면 또 갈립니다. TUN은 커널이 가상 인터페이스로 패킷을 넘기므로 프로세스가 프록시를 “알 필요”가 적어져, 인증·롱폴링·스트리밍처럼 연결이 길어지는 Anthropic API 패턴에 특히 안정적입니다. 물론 회사 노트북 정책이 가상 어댑터 설치를 막으면 예외가 있으니 준수 범위 안에서 선택해야 합니다.
이 글이 다루는 범위
여기서는 요금제·모델 등급·프롬프트 기법은 다루지 않습니다. 오직 외부 레이턴시 표면, 즉 어떤 FQDN을 관측했는지, 규칙 트리 어디에 두었는지, DNS 모드와 스니퍼·fake-ip-filter가 서로 모순되지 않는지에 집중합니다. 문서나 엔드포인트 문자열은 시점에 따라 바뀔 수 있으니, 아래 예시는 패턴 설명용이며 실제 문자열은 본인 환경의 로그·DevTools·프로세스 로그를 기준으로 교체해야 합니다.
1로그와 curl로 호스트 관측
Claude Code가 출력하는 오류 텍스트에 호스트 이름이 그대로 노출되는 경우가 많습니다. 그 문자열을 메모해 두고, 동일 시각에 Clash 연결 패널에서 어떤 규칙이 첫 매칭이었는지 타임스탬프로 맞춥니다. 가능하면 브라우저와 터미널 양쪽에서 같은 호스트를 동시에 호출해 한쪽만 실패하는지 비교하세요. 간단 검사로는 다음처럼 TLS 지연만 먼저 보는 방법이 있습니다. 실제 경로는 엔드포인트 문서와 권한에 맞게 바꿉니다.
# Example — adjust host/path and timeout for your test
curl -v -m 25 https://api.anthropic.com/결과의 연결 시도·ALPN·인증서 체인 단계별 초를 기록해 두면, 이후 DNS만 손댔는지 규칙만 손댔는지를 분리해 볼 수 있습니다. 로그 타임라인 읽기 팁은 연결 리셋 로그 글을 참고하세요.
2TUN 켜기와 예외 범위
클라이언트 UI에서 TUN을 활성화한 뒤, 사내 VPN·제로 트러스트 에이전트와 경로가 이중으로 잡히지 않는지 확인합니다. 로컬 빌드 서버나 사내만 허용된 레지스트리는 fake-ip-filter·직통 규칙으로 보호하고, 반드시 직통해야 하는 대역을 먼저 위쪽에 고정합니다. Windows 초기 설치가 필요하면 Windows Clash 설치 튜토리얼부터 정리한 뒤 TUN을 켜면 변수가 줄어듭니다.
3분류 규칙 초안 — Anthropic 묶음
아래는 설명용 스케치입니다. 실제 프로파일에는 거대 RULE-SET·GEOIP 줄이 이미 있으므로, 사용자 전용 파일에 모았다가 Mixin으로 덧붙이는 방식이 안전합니다. 핵심은 “관측한 호스트 이름 전체”를 같은 정책 그룹으로 보내 첫 프레임부터 출구가 흔들리지 않게 하는 것입니다.
# Illustration — replace PROXY_ANTHROPIC; verify order vs RULE-SET/MATCH
rules:
- DOMAIN-SUFFIX,api.anthropic.com,PROXY_ANTHROPIC
- DOMAIN-SUFFIX,anthropic.com,PROXY_ANTHROPIC
- DOMAIN-SUFFIX,claude.ai,PROXY_ANTHROPIC
# Add exact hosts you see in CLI logs (stats, CDN, telemetry)
- MATCH,DIRECT참고: 통계·실험 플래그 호스트는 제품 업데이트로 자주 바뀝니다. 문자열 하나에 의존하기보다 로그에 새 이름이 보일 때마다 목록 파일을 갱신하는 습관이 장기적으로 더 안전합니다. 규칙 순서는 위에서 아래로 첫 매칭이 이깁니다.
웹 인증 호스트와 API 호스트를 나눌까
초기 디버깅에서는 두 줄을 한 그룹에 묶는 편이 역추적이 쉽습니다. 증상이 사라진 뒤 회사 정책상 웹만 직통해야 한다면 그때 claude.ai와 api.anthropic.com을 분리하되, 리다이렉트 연쇄가 생기는지 로그로 다시 확인하세요. 분할 판단에 대한 일반 논리는 Claude 웹·API 분할 글의 서술과 같습니다.
4DNS·FakeIP·스니퍼 정합성
브라우저 Secure DNS와 코어 DNS가 동시에 켜져 있으면 이름 해석만 어긋나 규칙이 헛도는 것처럼 보일 수 있습니다. Meta 코어에서는 fake-ip-filter 범위와 스니퍼 활성 여부를 함께 맞추고, 변수는 한 번에 하나만 바꿔 재현 가능한 로그를 남기세요. 세부는 DNS 유출 방지 가이드와 HTTPS 스니퍼 글을 참고합니다.
5정책 그룹·재검증
스트리밍 응답은 작은 패킷 손실만 있어도 상한 시간을 넘기 쉬워 url-test가 공격적으로 노드를 바꾸면 세션이 끊긴 것처럼 보입니다. 디버깅 동안에는 selector로 단일 노드를 고정해 비교한 뒤, 안정이 확인되면 다시 자동 그룹을 켭니다. 자동 장애조치 패턴은 url-test·fallback 글을 보세요.
WSL2·원격 개발 환경
Windows에서 Docker·WSL 안의 프로세스까지 같은 방식으로 맞추려면 게이트웨이와 포워딩이 추가로 필요합니다. 호스트 OS의 TUN이 패킷을 받아도 게스트 브리지가 다르면 CLI는 또 다른 경로를 탑니다. 절차는 WSL2·Git·npm 연계 글과 함께 보는 것이 가장 빠릅니다. macOS Linux VM을 쓴다면 NAT·루프백 예외를 별도로 점검해야 합니다.
CLI 안정성 간이 체크리스트
- 실패 로그에 나온 모든 호스트 이름을 한 목록으로 모았는지.
- 그 목록이 규칙 트리에서 어떤 줄에 첫 매칭되는지 연결 패널과 시간축이 일치하는지.
- TUN ON/OFF에 따라 증상이 근본적으로 바뀌는지, 바뀐다면 아직 앱 레벨 프록시에 의존하는 패스가 남았는지.
- 브라우저 Secure DNS·OS DNS·코어 DNS가 교차 간섭하지 않는지.
- 변경을 한 줄씩만 적용했는지(여러 스위치를 동시에 움직이면 원인 분리가 어려움).
자주 묻는 질문
시스템 프록시만으로는 부족한 이유는
일부 런타임은 macOS·Windows의 시스템 프록시 테이블을 읽지 않습니다. 프록시를 읽더라도 PAC/자동 설정과 수동 프록시가 섞이면 CONNECT만 되고 일반 CONNECTless 경로는 빠지는 사례가 있습니다. TUN은 이런 차이를 커널에서 흡수합니다.
TUN과 규칙을 맞췄는데도 지연이 크다면
물리 왕복 자체가 길거나 노드 품질 문제일 수 있습니다. 동일 시각에 간단한 정적 파일 다운로드로 베이스라인을 잡고, 스트리밍 엔드포인트만 문제인지 비교하세요. 지역 규제·차단이 아니라면 타 노드·타 프로토콜 실험이 다음 단계입니다.
정책·약관 준수
조직 네트워크 규정과 클라우드 데이터 처리 지침을 지키세요. 키·세션 토큰·샘플 응답은 공개 채널에 붙이지 말고, 문서에 새 엔드포인트가 올라왔는지 수시로 교차 확인합니다.
준수: 회사 보안·로깅 정책을 위반하지 마세요. 진단 중 수집한 URL·키는 로컬에만 보관하고, 불필요한 전송을 줄입니다.
맺음말
Claude Code 같은 CLI는 짧은 재시도만 반복해도 전체 체감이 “항상 타임아웃”처럼 느껴집니다. 브라우저와 달리 프록시 인식이 들쭉날쭉한 환경에서는 TUN으로 트래픽을 한 파이프에 올린 뒤, 관측 기반으로 Anthropic 호스트 묶음을 분류 규칙에 고정하고 DNS·FakeIP를 같은 축에서 맞추는 세트가 가장 재현성이 높습니다. 이미 웹 글에서 다룬 패턴을 CLI에 복제하되, 터미널 특유의 루프백·WSL·HTTP3 변수를 추가로 빼면 같은 도구로 다른 모델에도 그대로 이식할 수 있습니다.
한편 수많은 범용 프록시 도구는 여전히 장문의 설정 파일을 수동으로 맞추거나, 터미널마다 환경 변수를 중복 정의해야 해서 실수 여지가 큽니다. Clash 계열은 GUI에서 프로파일과 규칙 트리를 바로 보고, Meta 코어 기능과 결합해 DNS·TUN·프로세스별 분기까지 한 제품군 안에서 실험할 수 있어 AI 코딩 회선을 자주 바꾸는 사람에게 특히 시간을 아껴 줍니다. 아직 쓰지 않았다면 Clash 클라이언트를 무료로 받아 본문 순서대로 Claude Code 세션을 다시 돌려 보고, 인증·모델 동기화·긴 응답 스트림이 동시에 안정되는지 직접 비교해 보시길 권합니다.