Claude Code 네트워크 안정화 가이드

Claude Code는 가정용 인터넷, 기업 네트워크, 관리되는 프록시, 규정을 준수하는 기업 게이트웨이에서 사용할 수 있습니다. 일반 계정이라면 소유 관계가 명확하고 오랫동안 안정적인 네트워크가 공용 VPN, 공유 프록시 풀, 자주 바뀌는 VPS 출구 IP보다 대체로 낫습니다. 설정하기 전에 청정도 검사로 현재 IP 유형과 위험 점수를 확인하세요.

ISP 재접속으로 IP가 자연스럽게 바뀌는 것은 계정이 여러 국가를 넘나드는 것과는 보통 다릅니다. 더 주의해야 할 것은 짧은 시간 안에 여러 국가, 여러 ASN, 여러 기기 사이를 자주 오가는 경우이며, 이는 계정 보안 검토를 받을 가능성을 높입니다.

QUIC(UDP 443) 프로토콜은 일부 프록시나 기업 방화벽 환경에서 패킷 손실, 시간 초과, 예상과 다른 전달 문제가 생기기 쉽습니다. 연결이 간헐적으로 끊기면 QUIC를 비활성화하거나 Claude 관련 트래픽을 TCP 전용으로 강제한 뒤 다시 테스트해 보세요.

"network": "tcp"
# 또는 클라이언트 수준에서 QUIC 비활성화

클라이언트마다 TLS 핸드셰이크 특성이 다를 수 있습니다. 프록시 체인이 TLS 동작을 바꾸거나 인증서를 주입하거나 지나치게 비정상적인 클라이언트 핑거프린트를 사용하면 연결 실패나 추가 인증이 발생할 수 있습니다. 검증된 클라이언트와 표준 TLS 설정을 우선 사용하세요.

"tls": {
  "fingerprint": "chrome"
}

DNS 리졸버, HTTP 출구, 브라우저 출구는 같은 네트워크 경로에서 나오는 것이 가장 좋습니다. DNS는 로컬에서 해석하고 HTTP는 프록시를 거치면 해석된 지역과 접속 지역이 일치하지 않을 수 있습니다. 신뢰할 수 있는 DoH/DoT를 써도 되지만, 핵심은 라우팅 규칙이 실제로 DNS 트래픽까지 포함하는지 확인하는 것입니다.

"dns": {
  "servers": ["https://1.1.1.1/dns-query"]
}

프록시나 라우팅 규칙이 IPv4만 처리하면 IPv6 트래픽이 다른 경로로 나가, HTTP / DNS / WebRTC에서 보이는 출구가 서로 다를 수 있습니다. 항상 IPv6를 꺼야 하는 것은 아니지만, 먼저 듀얼 스택 일관성을 확인해 보는 것이 좋습니다. 자세한 내용은 IPv6 듀얼 스택 위험을 참고하세요.

ipv6 = false
# 또는 프록시 domainStrategy: "UseIPv4"

공식 문서에 따르면 Claude Code의 네트워크 접근 대상에는 최소한 api.anthropic.com, claude.ai, statsig.anthropic.com, sentry.io가 포함됩니다. 문제 해결과 감사가 쉽도록 이 도메인들에 전용 라우팅 규칙을 만드는 것을 권장합니다. Claude Code 라우팅 규칙을 참고하세요.

Claude 웹, 로그인, 문서, 정적 리소스는 버전에 따라 서로 다른 CDN이나 서드파티 서비스를 사용할 수 있습니다. 주 도메인 하나만 하드코딩하지 마세요. 공식 필수 도메인을 기준으로 삼고, 로컬 패킷 캡처나 로그로 실제 접속하는 정적 리소스 도메인을 추가하세요.

연결이 자주 끊기고 다시 연결되면 지연 시간이 늘고 프록시 체인의 문제 해결도 어려워집니다. 프록시 클라이언트에서는 적절한 TCP keep-alive를 켤 수 있습니다. 연결 다중화(mux) 사용 여부는 회선 품질에 따라 정하세요. 다중화 막힘이나 단일 연결 속도 제한이 나타나면 끈 뒤 비교해 보세요.

Claude Code 호출을 바깥에서 대량의 동시 작업자(worker)로 감싸지 마세요. 동시 실행이 과도하면 속도 제한, 연결 대기열, 기업 게이트웨이 스로틀링이 발생할 수 있습니다. 실제 임계값은 계정 요금제, 조직 정책, API 응답에 따라 다릅니다.

지리적 거리만 보지 말고, 패킷 손실과 지터가 낮고 Anthropic API까지 경로가 안정적인 출구를 우선 선택하세요. 유출 테스트와 실제 Claude Code 요청 지연 시간을 함께 보고 판단하세요.