会社のネットワークからClaude Codeを使うと、次のようなメッセージで接続できないことがあります。
SSL certificate verification failed. Check your proxy or corporate SSL certificates
Unable to connect to API: Self-signed certificate detected. Check your proxy or corporate SSL certificatesプロキシやファイアウォールがTLS通信を仲介している環境で発生します。
社内のTLS検査プロキシや独自CAなどが主な確認対象です。
個人PCでも起こり得るため、発生頻度だけで原因を判断しないでください。
ログイン時は原因コードまで表示される
/login や起動時の接続チェックで失敗した場合は、OpenSSLのエラーコードと対処法が同時に表示されます。
SSL certificate error (UNABLE_TO_GET_ISSUER_CERT_LOCALLY). If you are behind a corporate
proxy or TLS-intercepting firewall, set NODE_EXTRA_CA_CERTS to your CA bundle path,
or ask IT to allowlist *.anthropic.com. Run `claude doctor` for details.原因の切り分けには claude doctor コマンドが使えます。
対処法：CA証明書のパスを指定する
管理者から正規のCA証明書バンドルを入手し、必要に応じて環境変数へパスを設定します。
次はBash・Zshの例です。
設定後は、その環境からClaude Codeを起動し直してください。
export NODE_EXTRA_CA_CERTS=/path/to/ca-bundle.pem証明書の入手方法は管理者に確認し、組織のCAがOSへ登録済みなら、追加ファイルの設定が必要かを先に確認します。
公式ネットワーク資料では、OS証明書ストアの読み込みはネイティブ版で対応し、npm版はNode.js 22.15以降が必要です。
NODE_EXTRA_CA_CERTSを指定した場合は、claude --debugで起動し、~/.claude/debug/内の対象セッションのログで追加CAの読み込み成功または失敗理由を確認します。
/statusの「Additional CA cert(s)」にパスが表示されても、ファイルを読み込めた証拠にはなりません。
社内プロキシの許可リストを変更する場合は、管理者に*.anthropic.comだけでなく、ログインに使うclaude.ai・claude.com・platform.claude.comなど、利用機能に必要な接続先を確認してもらってください。
避けるべき回避策
NODE_TLS_REJECT_UNAUTHORIZED=0 は設定しないでください。
これは証明書の検証自体を無効化する設定です。
公式ドキュメントでも、この設定を使用しないよう明記されています。
接続が通る場合があっても、通信相手が正当かどうかを確認しなくなります。
社内ネットワーク環境であっても、認証情報やソースコードを送信する経路で検証を無効にするのは重大なリスクがあります。
再試行の挙動に関する仕様変更
証明書の検証失敗は、v2.1.199以降は再試行されません。
そのため初回で即座にエラーが表示されます。
以前のバージョンでは数分間再試行を繰り返してから表示されていました。
「以前は待たされたのに、現在はすぐ失敗する」と感じる場合、この仕様変更が関係する可能性があります。
エラーコードとバージョンも照合します。
なお、TLSハンドシェイクのタイムアウトなど一時的な通信失敗については、引き続き再試行されます。
クラウドセッションで特定のホストのみ遮断される場合
Claude Code on the web やルーチンの実行中に、次のようなエラーで失敗することがあります。
HTTP 403
x-deny-reason: host_not_allowedこれは手元のローカルネットワークの問題ではありません。
クラウドセッションはサンドボックス内で稼働しており、外部への通信が環境の許可リストによって制限されています。
既定の環境は Trusted access であり、パッケージレジストリやクラウドAPI、一般的な開発用ドメインへの通信は許可され、それ以外は遮断されます。
GitHub操作やMCPコネクタは別経路を使用するため、そちらだけ正常に動作し続ける場合があります。
このクラウドの許可リストによる拒否では、プロキシが接続を終端して宛先と異なる証明書が見えることもあります。
すべての証明書不一致を同じ原因と判断しないでください。
許可リストに追加する
- ルーチンを編集で開くか、クラウドセッションを開始する
- 環境名（Default など）が表示されたクラウドのアイコンを選び、セレクタを開く
- 環境にカーソルを合わせて設定アイコンをクリックする
- Network access を Trusted から Custom に変え、Allowed domains にドメインを1行ずつ追加する
- 既定の許可リストも残す場合は該当チェックを入れ、Save changesで保存する。組織共有環境はセレクタ内ではOwnerを含め読み取り専用なので、Ownerが管理設定のCloud environmentsから変更する
Anthropicがホストする環境では、許可リスト経由の通信に対する変更は既存セッションにも約1分で反映されるため、保存後に対象ホストへの接続を再確認します。
起動しない・インストールできない場合の切り分け手順はこちらをご確認ください。
Claude Codeのエラー対処は、ほかにも書いています。
まとめ
- SSLエラーは原因コードを確認し、OS証明書ストアや NODE_EXTRA_CA_CERTS で正規のCAを信頼させる
- NODE_TLS_REJECT_UNAUTHORIZED=0 は使わない
- 原因コードの確認は claude doctor
- 証明書の失敗は v2.1.199 以降すぐエラーになる（再試行しない）
- クラウドセッションの host_not_allowed は環境の許可リストの問題。
手元の設定ではない
ほかのメッセージはClaudeのエラーメッセージ一覧に整理しています。
この記事は2026年10月27日に、公式エラー資料とネットワーク・クラウド環境の資料を再照合して更新しています。
冒頭の短いエラー文は旧版の例で、v2.1.273以降は原因コードとCA設定の案内が追加されています。
よくある質問：社内ネットワークでのClaude CodeのSSLエラー
会社のネットワークで、Claude Codeが接続できないのはなぜですか？
プロキシやファイアウォールがTLS通信を仲介している環境で起きます。
社内のTLS検査プロキシや独自CAなどが主な確認対象です。
個人PCでも起こり得るため、発生頻度だけで原因を判断しないでください。
/login や起動時の接続チェックで失敗した場合は、OpenSSLのエラーコードと対処法が同時に表示され、原因の切り分けには claude doctor コマンドが使えます。
SSLエラーは、どう直しますか？
正規のCAを信頼させる方法を確認します。
対応ランタイムでのOS証明書ストア、または NODE_EXTRA_CA_CERTS によるCAバンドル指定が候補です。
シェルの環境変数を変えたらClaude Codeを起動し直します。
証明書の入手方法は、情報システム部門など社内の管理者に確認します。
社内プロキシの許可リストを変更する場合は、管理者に*.anthropic.comだけでなく、ログインに使うclaude.ai・claude.com・platform.claude.comなど、利用機能に必要な接続先を確認してもらってください。
NODE_TLS_REJECT_UNAUTHORIZED=0 を設定して、回避してもよいですか？
設定しないでください。
証明書の検証自体を無効化する設定で、公式ドキュメントでも、使用しないよう明記されています。
接続が通る場合があっても、通信相手が正当かどうかを確認しなくなり、社内ネットワーク環境であっても、認証情報やソースコードを送信する経路で検証を無効にするのは重大なリスクがあります。
以前は待たされたのに、今はすぐエラーになるのは？
証明書の検証失敗は、v2.1.199以降は再試行されないため、初回で即座にエラーが表示されます。
以前のバージョンでは、数分間再試行を繰り返してから表示されていました。
TLSハンドシェイクのタイムアウトなど、一時的な通信失敗については、引き続き再試行されます。
クラウドセッションで、特定のホストだけ遮断されるのは？
Claude Code on the web やルーチンの実行中に失敗することがあり、手元のローカルネットワークの問題ではありません。
クラウドセッションはサンドボックス内で稼働していて、外部への通信が環境の許可リストによって制限されています。
既定の環境は Trusted access で、パッケージレジストリやクラウドAPI、一般的な開発用ドメインへの通信は許可され、それ以外は遮断されます。
GitHub操作やMCPコネクタは別経路を使うため、そちらだけ正常に動作し続ける場合があります。
クラウドの許可リストによる拒否では、プロキシ終端による証明書の違いが見えることもあります。
他の証明書エラーとは切り分けます。
許可リストにホストを追加するには？
ルーチンを編集で開くか、クラウドセッションを開始し、環境名（Default など）が表示されたクラウドのアイコンを選んでセレクタを開きます。
環境にカーソルを合わせて設定アイコンをクリックし、Network access を Trusted から Custom に変えて、Allowed domains にドメインを1行ずつ追加します。
既定リストを含める設定を確認して保存し、共有環境ならOwnerに管理設定のCloud environmentsから変更してもらいます。
公式資料では、Anthropicがホストする環境の許可リスト経由の通信には、既存セッションでも約1分で変更が反映されます。
記事の確認時点と、そのほかの注意は？
記事は、2026年10月27日に、公式エラー資料とネットワーク・クラウド環境の資料を再照合しています。
起動しない・インストールできない場合の切り分けや、ほかのエラーメッセージは、関連記事（Claudeのエラーメッセージ一覧など）にまとめられています。
バージョンや画面の表記は変わるため、最新は公式資料で確認してください。
今回は各OSの証明書・社内プロキシ・許可リスト変更や画面操作を実機で検証していません。
