Claude Code 403 오류: 지역 제한, 게이트웨이, TLS, 로그인 문제

Claude Code에서 HTTP 403이 발생했다는 사실만으로 계정이 차단됐다고 판단할 수는 없습니다. 여기서 다루는 진단, 게이트웨이, 인증서 수정 사항을 적용하려면 Claude Code 2.1.318 이상을 사용합니다. 그런 다음 로그인을 반복하지 말고 오류 내용에 맞는 원인을 확인합니다.

2.1.317 릴리스 노트는 지역·네트워크 차단과 로그인 실패를 구분합니다. 2.1.318 릴리스 노트는 문제가 있는 인증서 파일의 처리와 저장된 로그인 만료 안내를 개선합니다. 이러한 변경은 실패 원인을 파악하는 데 도움이 됩니다. 접근 제한을 해제하거나 모든 게이트웨이 설정을 고치는 변경은 아닙니다.

수정된 버전과 작은 요청부터 확인합니다

2026-11-10 기준으로 이 수정 사항을 모두 포함하는 최소 버전은 2.1.318입니다. 2.1.318이 최신 버전이라는 뜻은 아닙니다. 각 수정 사항이 처음 포함된 버전은 다음과 같습니다.

증상	해당 수정이 처음 포함된 버전	먼저 확인할 사항
지역·네트워크 차단으로 발생한 HTTP 403이 로그인 실패로 표시됩니다	2.1.317	차단 설명을 읽고 응답한 서비스를 식별합니다
지역·네트워크 차단 후 VS Code가 로그인 화면을 엽니다	2.1.317	문제가 발생한 VS Code 인터페이스에서 다시 시도합니다
Base URL로 설정한 게이트웨이가 안전 검사에 403 또는 422를 반환하면 Auto가 매 턴 실패합니다	2.1.317	Manual과 Auto를 비교합니다. apiKeyHelper 사용 시 403 예외는 그대로입니다
TLS 검사 프록시의 루트 인증서 갱신 후 unable to get local issuer certificate가 발생합니다	2.1.317	승인된 인증서 체인과 클라이언트 버전을 확인합니다
NODE_EXTRA_CA_CERTS 파일이 비어 있거나 PEM이 아니거나 첫 인증서가 손상되어 연결이 실패합니다	2.1.318	인증서 파일을 수정하고 시작 시 경고를 확인합니다
필수 Claude apps gateway에 연결할 수 없습니다	2.1.317	네트워크 경로와 인증서 신뢰 설정을 확인합니다
저장된 claude.ai 로그인의 유효 기간이 끝납니다	2.1.318	네트워크 설정 대신 사용 중인 로그인을 갱신합니다

Bash에서 실제로 사용하는 CLI를 확인합니다.

claude --version
claude auth status

CLI 참조 문서는 claude auth status를 인증 상태를 보고하는 명령으로 설명합니다. 이 결과는 설정된 인증 상태를 확인하는 근거입니다. 모델 요청이 정상 작동한다는 증거는 아닙니다.

설치 방식에 맞는 지원되는 업데이트 방법을 사용합니다. 네이티브 방식으로 설치했다면 다음을 실행합니다.

claude update
claude --version

패키지 관리자로 설치했거나 조직에서 중앙 관리하는 설치라면 설치 및 업데이트 안내를 따릅니다. 표시된 버전이 필요한 최소 버전 이상인지 확인합니다. 재시도는 실패가 발생한 인터페이스에서 진행합니다. 터미널 테스트에 성공했다고 해서 VS Code의 연결 경로까지 정상이라고 판단할 수는 없습니다.

다음으로 같은 Bash 환경에서 작은 요청을 보냅니다.

claude -p 'Reply with exactly OK. Do not use tools.'

예상 결과는 연결이나 인증 오류 없이 OK가 반환되는 것입니다. 이 테스트는 기본적인 모델 요청을 확인합니다. Auto 모드의 검토 경로나 모든 기능과의 호환성을 확인하는 테스트는 아닙니다.

지역·네트워크 차단은 로그인 만료와 다릅니다

오류가 차단을 가리키면 네트워크나 접근 거부 사유를 조사합니다. 이 증상에서는 재인증이 첫 번째 해결책이 아닙니다.

2.1.317 변경 기록을 번역하면 다음과 같습니다.

지역 또는 네트워크 차단(HTTP 403)이 로그인 실패로 표시되는 문제를 수정했습니다. 이제 오류가 차단 내용을 설명합니다.

같은 릴리스는 이 상황에서 VS Code가 로그인 화면을 여는 문제도 별도로 수정합니다. 두 항목 모두 업데이트하면 차단된 요청이 허용된다고 설명하지는 않습니다.

Claude Code를 시작하고 /status를 실행합니다. 게이트웨이 연결 안내에 따라 활성 경로와 인증 정보 출처를 확인합니다. 계정을 조사하기 전에 요청이 Anthropic으로 직접 전송되는지, 설정된 게이트웨이로 전송되는지 파악합니다.

회사 네트워크에서는 IT 담당자에게 해당 프로세스가 사용하는 프록시 설정을 확인해 달라고 요청합니다. 여기에는 HTTPS_PROXY와 HTTP_PROXY가 포함됩니다. 두 변수는 네트워크 설정 가이드에 설명되어 있습니다. 지역 차단이 확인됐다면 인증 정보를 반복해서 갱신하는 대신 제공업체에 서비스 이용 가능 여부를 확인합니다.

응답 본문, 대상 호스트 이름, 타임스탬프와 확인 가능한 요청 ID를 보관합니다. 지원 문의에 전체 환경 정보, 인증 정보 또는 전체 프롬프트를 보내면 안 됩니다.

계정 보류를 명시한 별도 안내가 있다면 계정 지원 경로로 처리합니다. Anthropic의 오류 참조 문서는 이를 계정이 정지된 상태로 설명합니다. 요청한 모델에 대한 접근 권한이 없는 경우도 있습니다. 설치 및 인증 가이드는 인증에 성공해도 계정이 해당 모델을 사용할 수 없으면 403이 발생할 수 있다고 설명합니다.

검증할 때는 의도한 승인된 경로로 작은 요청을 다시 보냅니다. 여전히 403이 반환되면 현재 오류 설명과 제공업체의 기록으로 거부 사유를 파악합니다. 상태 코드만으로 계정 차단을 단정하지 않습니다.

게이트웨이를 거치면 Auto가 매 턴 실패합니다

동일한 게이트웨이에서 Manual은 작동하지만 Auto가 반복해서 실패한다면 안전 검사 경로를 조사합니다. 2.1.317 수정 사항의 적용 범위는 구체적입니다. 변경 기록의 번역은 다음과 같습니다.

기본 URL로 설정된 LLM 게이트웨이가 서버 측 안전 검사에 403 또는 422를 반환할 때 Auto 모드가 매 턴 실패하는 문제를 수정했습니다. apiKeyHelper를 사용할 때의 403 동작은 변경되지 않았습니다.

이 예외를 놓치면 안 됩니다. apiKeyHelper가 활성화된 상태의 403은 이 변경의 적용 대상이 아닙니다. 게이트웨이 관리자에게 인증 정보와 권한 부여 과정을 확인해 달라고 요청합니다. 헬퍼가 출력하는 비밀 정보는 노출하지 않습니다.

게이트웨이 호환성 가이드는 서버 측 검토에 사용하는 anthropic-beta 값과 요청의 safeguards 필드를 설명합니다. 게이트웨이가 이 기능을 거부하는 문제와 인증 정보를 거부하는 문제는 서로 다르게 조사해야 합니다. 상태 코드만으로는 어느 쪽인지 알 수 없습니다.

신뢰할 수 있는 Git 저장소의 작업 사본에서 두 세션을 비교합니다. 모델, 엔드포인트, 인증 정보와 작업은 그대로 유지합니다.

claude --permission-mode default로 시작합니다. Claude에 Bash로 git status --short를 실행하고 파일을 변경하지 않은 채 결과를 보고하도록 요청합니다. 권한 승인 요청이 표시되면 승인합니다.

해당 세션을 종료한 뒤 claude --permission-mode auto로 시작하고 같은 작업을 반복합니다. 권한 모드 제어 안내를 참고해 요청한 모드가 실제로 활성화됐는지 확인합니다. Auto로 전환되지 않은 세션이 성공해도 Auto 비교 테스트에 성공한 것은 아닙니다.

Auto 세션에서만 실패하면 실패한 요청을 게이트웨이 기록과 대조합니다. 게이트웨이 운영자에게 호환성 가이드에 따라 거부 사유를 조사해 달라고 요청합니다. 이 비교는 조사 범위를 좁혀 줍니다. 원인이 된 구체적인 게이트웨이 규칙까지 입증하지는 않습니다.

관리자의 승인을 받으면 임시 진단을 위해 서버 측 검토 대신 Claude Code 자체 분류기의 요청을 사용할 수 있습니다. 이 분류기는 작업을 평가합니다.

CLAUDE_CODE_AUTO_MODE_SERVER=0 claude --permission-mode auto

환경 변수 참조 문서에 이 전환 설정이 설명되어 있습니다. 검토가 이루어지는 위치를 바꾸는 설정이며 권한 검사를 끄지는 않습니다. 분류기는 계속 모델 요청을 보냅니다. 이 설정을 유지하기 전에 요청 사용량과 지연 시간을 확인합니다.

이 세션은 작동하지만 일반 Auto는 실패하면 서버 측 검토와의 호환성을 조사합니다. 둘 다 실패하면 표시된 인증 정보, 모델 또는 게이트웨이 오류를 조사합니다. 이번 수정 사항이 해당 오류에도 적용된다고 가정하지 않습니다.

요금 차이는 서버 측 분류기 과금과 대체 처리 방식에서 확인할 수 있습니다. 분류기의 별도 요청 경로를 오프라인 방식이나 반드시 무료인 대안으로 취급하면 안 됩니다.

인증 대신 인증서 신뢰 문제를 수정합니다

unable to get local issuer certificate는 인증서 신뢰 문제로 다룹니다. HTTP 권한 응답과는 다른 계층에서 발생하는 실패입니다.

2.1.317 변경 기록을 번역하면 다음과 같습니다.

일부 TLS 검사 프록시에서 루트 인증서 갱신 후 API 요청이 “unable to get local issuer certificate”로 실패하는 문제를 수정했습니다.

이 수정은 설명된 인증서 갱신 문제에 해당합니다. 발급자 인증서와 관련된 모든 오류가 같은 원인이라는 뜻은 아닙니다.

먼저 클라이언트 버전을 확인합니다. 그런 다음 IT 담당자에게 프록시의 루트 인증서가 변경됐는지, 클라이언트가 어떤 인증 기관(CA)의 인증서 묶음을 신뢰해야 하는지 확인합니다. 검증되지 않은 출처에서 복사한 인증서 대신 승인된 PEM 묶음을 사용합니다.

환경에 별도의 인증서 묶음이 필요하다면 IT 담당자가 제공한 파일을 $HOME/company-ca.pem으로 저장합니다. 같은 Bash 셸에서 새로운 Claude Code 프로세스를 시작합니다.

export NODE_EXTRA_CA_CERTS="$HOME/company-ca.pem"
claude -p 'Reply with exactly OK. Do not use tools.'

이는 문서에 안내된 사용자 지정 CA 설정을 따릅니다. 예제의 경로는 사용자가 선택하는 로컬 파일 이름입니다. 실제 인증서 내용은 소속 조직에서 제공한 것이어야 합니다.

발급자 인증서 오류 없이 요청이 완료되면 검증에 성공한 것입니다. 여전히 실패하면 IT 담당자에게 제공된 묶음과 프록시를 통해 제시되는 인증서 체인을 확인해 달라고 요청합니다.

NODE_TLS_REJECT_UNAUTHORIZED=0을 설정하면 안 됩니다. Anthropic의 인증서 오류 안내는 이 설정이 인증서 검증을 비활성화한다고 경고합니다.

비어 있거나 손상된 NODE_EXTRA_CA_CERTS 파일

추가 CA 파일 자체가 잘못됐다면 2.1.318 이상을 사용합니다. 변경 기록을 번역하면 다음과 같습니다.

NODE_EXTRA_CA_CERTS 파일이 비어 있거나 PEM이 아니거나 손상된 인증서로 시작할 때 모든 연결이 실패하는 문제를 수정했습니다. 이제 읽을 수 있는 인증서를 사용하며 stderr에 경고를 출력합니다.

최종 연결 결과뿐 아니라 경고도 확인합니다. 이 수정은 읽을 수 있는 인증서를 사용하도록 하는 변경입니다. 파일을 복구하거나 프록시에 필요한 누락된 인증서를 제공하지는 않습니다.

비어 있거나 손상된 묶음을 승인된 PEM 파일로 교체합니다. 실수로 지정한 NODE_EXTRA_CA_CERTS 설정은 해당 환경에 필요하지 않다는 점을 확인한 뒤에만 제거합니다. 그런 다음 새 프로세스를 시작하고 작은 요청을 반복합니다.

요청에 성공하더라도 인증서 파일 경고가 남아 있다면 묶음을 수정합니다. 경고가 남은 상태에서 설정이 완료됐다고 판단하지 않습니다.

필수 Claude apps gateway에 연결할 수 없습니다

정상적인 로그인을 변경하기 전에 필수 게이트웨이와의 연결을 복구합니다. 2.1.317 항목의 번역은 다음과 같습니다.

필수 Claude apps gateway에 연결할 수 없을 때의 시작 오류를 개선했습니다. 이제 로그인 대신 네트워크 문제를 안내하며, 게이트웨이의 TLS 인증서를 검증할 수 없을 때도 명시합니다.

이 항목은 필수 Claude apps gateway에 관한 내용입니다. 모든 타사 ANTHROPIC_BASE_URL 엔드포인트에 자동으로 적용된다고 판단하면 안 됩니다.

게이트웨이 관리자에게 문제가 발생한 호스트 이름과 민감한 정보를 제거한 오류 메시지를 전달합니다. 서비스 접근 가능 여부, DNS, 프록시 정책과 인증서 신뢰 설정을 확인해 달라고 요청합니다. 메시지가 인증서 검증 문제를 가리키면 인증 정보를 초기화하지 말고 CA 점검 절차를 따릅니다.

검증은 두 단계로 진행합니다. 먼저 Claude Code가 게이트웨이 시작 오류 없이 실행돼야 하며, 이어서 작은 모델 요청도 완료해야 합니다. 이후 인증 오류가 나타나면 별도의 결과로 조사합니다.

해당 인증 정보가 만료됐을 때만 로그인을 갱신합니다

오류가 저장된 claude.ai 로그인의 만료를 명시하면 해당 로그인을 갱신합니다. 2.1.318 릴리스 노트는 이를 네트워크 차단과 구분합니다. 번역은 다음과 같습니다.

저장된 claude.ai 로그인이 유효 기간에 도달할 때의 로그인 실패를 수정했습니다. 이제 만료됐음을 설명하며, claude -p에서는 claude auth login과 claude setup-token을 안내합니다.

claude.ai 로그인을 사용해야 하는 대화형 작업이라면 Bash에서 다음 명령을 실행합니다.

claude auth login
claude auth status
claude -p 'Reply with exactly OK. Do not use tools.'

로그인을 완료한 뒤 상태를 확인하고 요청을 보냅니다. 예상 결과는 의도한 인증 상태가 확인되고 이어서 정상 응답을 받는 것입니다.

이 릴리스는 비대화형 환경에서 접근을 복구하는 방법으로 claude setup-token도 안내합니다. 스크립트에 토큰을 넣지 말고 해당 방식의 인증 안내를 따릅니다.

게이트웨이가 발급한 인증 정보는 발급 주체를 통해 복구해야 합니다. claude.ai에 로그인하는 것은 그 인증 정보를 검증하는 방법이 아닙니다. 로그인을 갱신해도 지역, 네트워크 또는 게이트웨이 오류가 계속 발생하면 해당 점검 절차로 돌아갑니다. 로그인을 반복하지 않습니다.

ANTHROPIC_BASE_URL과 활성 인증 정보를 확인합니다

설정을 더 바꾸기 전에 실패가 발생하는 세션 안에서 연결 경로를 확인합니다. 연결 가이드는 실제 Base URL과 인증 정보 출처를 확인하는 명령으로 /status를 권장합니다.

게이트웨이 문서에 안내된 Anthropic 호환 기본 주소를 사용합니다. 프로토콜 가이드는 ANTHROPIC_BASE_URL을 Anthropic Messages 형식 및 /v1/messages와 연결합니다. 프로토콜을 확인하지 않고 OpenAI 호환 URL을 이 설정에 복사하면 안 됩니다. 차이는 Base URL과 엔드포인트 문제 해결 가이드에서 설명합니다.

게이트웨이가 요구하는 헤더에 맞춰 인증 정보 변수를 선택합니다. Anthropic 문서에서 ANTHROPIC_AUTH_TOKEN은 Authorization: Bearer에, ANTHROPIC_API_KEY는 X-Api-Key에 사용하는 인증 정보입니다. 같은 인증 정보를 모든 변수에 넣지 말고 게이트웨이 지침을 따릅니다.

기존 BetterToken API 연결을 사용하는 경우, Claude Code 안내는 /v1이 없는 https://bettertoken.ai와 ANTHROPIC_AUTH_TOKEN을 사용합니다. 2026-11-10 기준으로 카탈로그에 claude-sonnet-5-5가 등록되어 있습니다. 이는 별도의 API 접근 방식이며 Claude 구독이 아닙니다. Claude Code의 모든 기능이 작동한다는 보장도 아닙니다.

실제 경로가 의도한 설정과 다르면 Claude Code의 활성 제공업체 확인 방법을 따릅니다. 작은 요청 하나를 의도한 제공업체의 기록과 대조한 뒤 이전에 실패한 작업을 다시 수행합니다. 기본 연결 확인에는 단순한 응답이면 충분합니다. Auto 모드 문제라면 Auto 비교 테스트도 성공해야 합니다.