結論から言う。社内ネットワークでClaude Codeが繋がらない原因は、ほぼ「プロキシを通していない」「TLS傍受の証明書を信頼していない」「ファイアウォールでホストが開いていない」の3つに割れる。そしてこの3つは、返ってくるエラーメッセージを読むだけで見分けられる。ECONNREFUSED や ERR_PROXY_TUNNEL ならプロキシ、UNABLE_TO_GET_ISSUER_CERT_LOCALLY や SELF_SIGNED_CERT_IN_CHAIN なら証明書、HTTP 200 なのに中身がAPIの応答でないなら途中の機器が答えている。
厄介なのは、設定を書いても効いているのか分からないことだ。Claude Codeはこれらの設定の大半を読み込み時に検証しないので、値が間違っていても起動は通り、あとの通信で初めて失敗する。だから「設定する手順」と「設定が読まれたことを確かめる手順」は分けて持っておく必要がある。以下は、切り分けから許可ホストの申請までを実際に触る順に並べたものだ。
この記事の要点
- 環境変数は起動時に一度だけ読まれる：走っているセッションは、あとからシェル側を書き換えても拾わない。設定したら起動し直す。
- プロキシは標準の変数でそのまま通る：
HTTPS_PROXY、HTTP_PROXY、NO_PROXYに対応し、小文字版も使える。ただしSOCKSプロキシには対応していない。 - 除外はスペース区切りでもカンマ区切りでもよい：
NO_PROXY="*"で全リクエストをプロキシ経由から外せる。 - TLS傍受の証明書は
NODE_EXTRA_CA_CERTS：組織のCAバンドルのパスを渡す。NODE_TLS_REJECT_UNAUTHORIZED=0での回避は公式に非推奨。 - OSの証明書ストアも既定で見に行く：既定値は
bundled,system。npm導入ではNode 22.15以降が必要で、それ未満だとOSストアは読まれない。 - クライアント証明書は3つの変数で渡す：
CLAUDE_CODE_CLIENT_CERT、CLAUDE_CODE_CLIENT_KEY、暗号化キー用のCLAUDE_CODE_CLIENT_KEY_PASSPHRASE。 - 効いているかは
claude --debugと/statusで読む：デバッグログは端末ではなく~/.claude/debug/<session-id>.txtに出る。 - シェルではなく設定ファイルに置く：背景セッションはシェルの環境を確実には引き継がないので、
~/.claude/settings.jsonのenvブロックに書く。 - 対象読者：社内プロキシやTLS傍受環境でClaude Codeを使う開発者、開発端末を配る情シス・プラットフォーム担当。
- 今日やること：
curl -I https://api.anthropic.comを同じシェルで1回叩いて、問題がClaude Code側なのかネットワーク側なのかを確定させる。
手順1｜まずエラーメッセージで原因を3つに割る
「繋がらない」と言う前に、返ってきた文言を読む。Claude Codeのネットワーク系エラーは、失敗の種類とコードを括弧付きで出すようになっていて、そこで原因がほぼ決まる。
接続そのものが失敗しているとき
TCP接続が失敗した、あるいは最後まで確立しなかった場合は Unable to connect to API 系のメッセージが出る。代表的なものを挙げる。
Connection refused — a firewall or proxy may be blocking it (ConnectionRefused)：ファイアウォールかプロキシが塞いでいる。Can't reach the API server — check your internet or DNS (ENOTFOUND)：名前が引けていない。No internet route — check your connection or VPN (EHOSTUNREACH)：経路がない。Couldn't connect through your proxy (ERR_PROXY_TUNNEL)：プロキシがトンネルを拒否した。資格情報と、そのホストへの接続が許可されているかを見る。Connection dropped (ECONNRESET)：確立済みの接続が切られた。
Connection refused は ConnectionRefused と ECONNREFUSED の両方のコードを取りうるなど、1つの文言が複数のコードを出すことがある。なお v2.1.227より前は、これらがすべて Unable to connect to API (コード) という同じ形だったので、古い版を使っているとこの切り分けができない。
証明書で止まっているとき
ネットワーク機器がTLSを傍受していて、Claude Codeがその証明書を信頼していない場合は、OpenSSLのコードが付いた専用のメッセージになる。
Unable to connect to API: SSL certificate verification failed (UNABLE_TO_GET_ISSUER_CERT_LOCALLY).
Unable to connect to API: Self-signed certificate detected (SELF_SIGNED_CERT_IN_CHAIN).
/login や起動時の接続チェックで同じ失敗が起きると、文言が変わって 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. のように対処まで書かれた形で出る。v2.1.199以降、証明書の検証失敗はリトライされないので、このエラーは初回の試行でそのまま出る。逆に言えば、数分待たされてから出るなら古い版だ。
途中の機器が代わりに答えているとき
いちばん分かりにくいのがこれだ。HTTPのステータスは 200 で返ってきているのに、中身がClaude APIのメッセージではない場合、API returned an empty or malformed response (HTTP 200) — check for a proxy or gateway intercepting the request. が出る。HTMLのエラーページ、空のボディ、別形式のJSONなどが典型で、プロキシ・ゲートウェイ・ネットワークのサインインページがAPIの代わりに答えているのが主な原因になる。
このメッセージには Response: の節が続き、コンテンツタイプ、ボディの種類（body is an HTML page、empty body など）、バイト数、Anthropicのリクエストidを持っていたかどうかが出る。nginx や cloudflare のような認識できるサーバー名や、cf-ray・via といった中継のヘッダーがあればそれも並ぶ。Anthropicのリクエストidが無い、HTMLのボディ、知らないサーバー名のどれかがあれば、APIまで届いていないと判断してよい。
まずは同じシェルから curl -I https://api.anthropic.com を叩く。Windows PowerShellでは組み込みの Invoke-WebRequest の別名が使われないよう curl.exe -I https://api.anthropic.com と書く。これが通ってClaude Codeだけ失敗するなら、ネットワークそのものではなくランタイムと設定の側が疑わしい。インストール自体が通らない段階で止まっている場合は、Claude Codeがインストールできない原因と対処7手順のほうが先だ。
手順2｜プロキシを環境変数で通す
原因がプロキシ側だと分かったら、標準の環境変数を設定する。Claude Codeは独自の変数を要求せず、よくあるプロキシ変数をそのまま読む。
設定する変数と書き方
# HTTPSプロキシ（推奨）
export HTTPS_PROXY=https://proxy.example.com:8080
# HTTPプロキシ（HTTPSが使えない場合）
export HTTP_PROXY=http://proxy.example.com:8080
小文字の変数名も使える。両方が設定されている場合、Claude Codeは https_proxy、HTTPS_PROXY、http_proxy、HTTP_PROXY の順に見て、最初に見つかったものを使う。社内の別ツール用に小文字版が既にexportされている端末では、自分が書いたつもりの大文字版が使われていないことがあるので、この順番は覚えておく。
重要な制限が1つある。Claude CodeはSOCKSプロキシに対応していない。社内の出口がSOCKSしかない環境では、この設定では通らない。
プロキシを通さない先を指定する
NO_PROXY は除外リストで、スペース区切りとカンマ区切りのどちらでも書ける。
# スペース区切り
export NO_PROXY="localhost 192.168.1.1 example.com .example.com"
# カンマ区切り
export NO_PROXY="localhost,192.168.1.1,example.com,.example.com"
# すべてのリクエストでプロキシを使わない
export NO_PROXY="*"
ループバック宛のWebSocket接続については、localhost、::1、127.0.0.0/8 をClaude Codeがプロキシへ送ることはないので、この3つを NO_PROXY に書き足す必要はない。ローカルのMCPサーバーが繋がらないときに真っ先にここを疑いがちだが、原因は別のところにある。
認証が要るプロキシ
Basic認証を要求するプロキシなら、資格情報をURLに含める。
export HTTPS_PROXY=http://username:password@proxy.example.com:8080
ただしスクリプトにパスワードを直書きするのは避け、環境変数か資格情報ストアを使うこと。NTLMやKerberosのような高度な認証が必要なプロキシについては、公式ドキュメントはこの形での対応を案内していない。その認証方式に対応したLLMゲートウェイを挟む方向を検討する、という書き方になっている。
プロキシがトンネルを開かないとき
Claude Codeは CONNECT でトンネルを要求するので、拒否されたときのステータスがそのまま原因を指す。アーティファクトの内容取得で出る例だが、読み方は共通だ。
| ステータス | 意味 | 対処 |
|---|---|---|
| HTTP 407 | 必要な資格情報が渡っていない | プロキシURLにBasic認証の資格情報を入れる |
| HTTP 403 | そのホストへのトンネルを拒否している | プロキシの運用者にそのホストの許可を依頼する |
| その他（HTTP 502など） | プロキシ自身の理由でトンネルを開けなかった | プロキシのログでステータスを調べる |
unreadable reply |
HTTPのステータス行が返っていない | そのアドレスが本当にHTTPプロキシか確認する |
切り分けには、自分のプロキシURLで curl -x http://proxy.example.com:8080 -I https://api.anthropic.com を、Claude Codeを起動するのと同じシェルから叩く。同じように失敗するならプロキシ設定側の問題で、成功するならClaude Code側の読み込みを疑う順番になる。
手順3｜TLS傍受プロキシの証明書を信頼させる
プロキシは通っているのに証明書エラーで止まる場合は、信頼ストアの話になる。ここは「何を信頼しているか」を先に理解しておくと早い。
既定で見ている証明書ストアは2つ
Claude Codeは既定で、同梱しているMozillaのCA証明書とOSの証明書ストアの両方を信頼する。OSストアを読むには tls.getCACertificates を持つランタイムが必要で、ネイティブインストーラー版は常に持っている。npm導入の場合はNode.js の tls.getCACertificates が使える Node 22.15以降が要る。それより古いNodeでは、同梱のCA集合と NODE_EXTRA_CA_CERTS だけが効く。
逆に言えば、組織のルート証明書がOSの信頼ストアに入っていて、ランタイムがそれを読める状態なら、TLS傍受プロキシは追加設定なしで通る。「CAは配布済みなのに繋がらない」ケースは、npm導入かつNodeが古い、という組み合わせであることが多い。
信頼元は CLAUDE_CODE_CERT_STORE で切り替えられる。カンマ区切りで、bundled（同梱のMozilla CA集合）と system（OSの信頼ストア）を指定する。既定は bundled,system だ。
# 同梱のMozilla CA集合だけを信頼する
export CLAUDE_CODE_CERT_STORE=bundled
# OSの証明書ストアだけを信頼する
export CLAUDE_CODE_CERT_STORE=system
この変数には settings.json の専用スキーマキーが無い。設定ファイルで渡すなら ~/.claude/settings.json の env ブロックに書くか、プロセスの環境変数として直接渡す。
CAバンドルを直接指定する
独自CAを使っている環境では、バンドルのパスを渡すのがいちばん確実だ。Node.js の NODE_EXTRA_CA_CERTS をそのまま使う。
export NODE_EXTRA_CA_CERTS=/path/to/ca-cert.pem
ここで絶対にやってはいけないのが NODE_TLS_REJECT_UNAUTHORIZED=0 での回避だ。公式ドキュメントは対処として明示的にこれを挙げ、証明書の検証そのものを無効化してしまうと書いている。傍受プロキシの内側で検証を切るのは、まさに検証が要る場所で検証を捨てることになる。
手順4｜クライアント証明書（mTLS）を出す
ゲートウェイ側がクライアント証明書を要求する構成では、証明書と秘密鍵をClaude Codeに渡す。
渡す3つの変数
# 認証用のクライアント証明書
export CLAUDE_CODE_CLIENT_CERT=/path/to/client-cert.pem
# クライアント秘密鍵
export CLAUDE_CODE_CLIENT_KEY=/path/to/client-key.pem
# 任意: 暗号化された秘密鍵のパスフレーズ
export CLAUDE_CODE_CLIENT_KEY_PASSPHRASE="your-passphrase"
Claude Codeは起動時にこれらのファイルを読み、さらに設定を適用するたびに読み直す。組織がセッション中に管理設定の env ブロックを変えたときなどがこれに当たる。
ローテーションの効き方は「監視」ではなく「失敗時の読み直し」
証明書と鍵を入れ替えるときは、同じパスのファイルを置き換える。走っているセッションは再起動なしで新しいペアを拾う——が、その拾うタイミングに癖がある。Claude Codeはファイルを監視していない。APIリクエストが接続レベルのエラー（接続リセットやTLSハンドシェイクの失敗）で落ちたときに両方のファイルを読み直し、新しいペアでリトライする。
- 置き換えた瞬間には何も起きない。条件に合う失敗のあとのリトライか、次に設定を適用したときのどちらか早いほうで新しいペアが出る。
- ゲートウェイがHTTPのエラーで返す場合は読み直さない。接続がリセットされる、またはTLSハンドシェイクが拒否される場合は読み直す。ハンドシェイクが成立したうえでHTTPエラーが返るケースでは、次の設定適用か再起動まで古いペアのままになる。
- 書き込み途中を読んだ場合は前のペアを保持する。証明書と鍵が互いに一致しない状態を読んだときは、それを採用せず次の失敗時にまた読み直す。
- OTLPテレメトリのエクスポーターは別。最初に使ったときの証明書を持ち続けるので、ローテーション後の証明書をテレメトリ収集側へ届けるにはClaude Code自体の再起動が要る。
なお、接続エラー時の読み直しはv2.1.232からの挙動だ。それ以前の版では、いったん読み込んだペアを、次の設定適用か再起動まで持ち続けていた。ローテーション運用を組むなら、配布している版がこれ以降かどうかを先に確認しておく。
手順5｜設定が読み込まれたかを確かめる
ここがこの記事でいちばん伝えたいところだ。Claude Codeは、この記事で挙げた設定の大半を読み込み時に検証しない。プロキシのアドレスが間違っていても、証明書のパスが存在しなくても、起動は通る。気づくのは、あとのリクエストが接続エラーや証明書エラーで落ちたときになる。
唯一の例外がプロキシURLの解析で、これだけは起動時にチェックされる。http:// のスキームが無い値のように解析できない値を渡した場合、Claude Codeはその時点で拒否する。裏を返せば、プロキシURLが構文として読めてさえいれば、宛先が間違っていても起動は通ってしまう。
claude --debug でログを読む
リクエストを送る前に設定が読み込まれたことを確認したいなら、デバッグログ付きで起動する。
claude --debug
出力は端末ではなく ~/.claude/debug/<session-id>.txt に書かれる。--debug-file <path> を付ければ任意のパスに出せる。ログの中で、それぞれのファイルが読み込まれたことを示す行を探す。
CA certs: Appended extra certificates from NODE_EXTRA_CA_CERTS (/etc/ssl/certs/corp-ca.pem)
mTLS: Loaded client certificate from CLAUDE_CODE_CLIENT_CERT
mTLS: Loaded client key from CLAUDE_CODE_CLIENT_KEY
読めなかった場合は、代わりに Failed to read または Failed to load の行が理由付きで出る。この行が出ていれば、ネットワークではなくパスや権限の問題だと断定できるので、切り分けが一気に短くなる。
対話セッションでは /status の行を見る
起動中のセッションからは /status を実行して、次の行を確認する。
| 行 | 表示されるもの | 注意点 |
|---|---|---|
| Proxy | 有効なプロキシURL | 解析できない値は invalid かつ無視された旨が付く |
| mTLS client cert | クライアント証明書 | 読み込めたときだけ行が出る |
| mTLS client key | クライアント鍵 | 読み込めたときだけ行が出る |
| Additional CA cert(s) | NODE_EXTRA_CA_CERTS のパス |
読み込めたかは確認しないので、デバッグログ側で裏を取る |
mTLSの2行は読み込めたときだけ表示されるという仕様が効いていて、行が無い＝読み込み失敗、と読める。一方で Additional CA cert(s) はパスを表示するだけで、そのファイルが実際に読めたかまでは見ていない。ここだけは /status を信じ切らず、claude --debug のログで確認する。
なお、起動時の接続チェックで失敗した場合は、失敗理由がそのまま出て終了する。
Unable to connect to Anthropic services
Failed to connect to api.anthropic.com: ECONNREFUSED
Connection to api.anthropic.com timed out after 10 seconds
A proxy is configured via HTTPS_PROXY. Check that it allows connections to the host above.
このチェックはAPIリクエストと同じプロキシ設定を通り、各プローブに10秒が与えられる。プロキシ経由で失敗したときは、どの環境変数がそのプロキシを設定したのかがメッセージに出るので、意図しない変数が効いていないかをここで確認できる。https:// スキームのプロキシURLでこのチェックが止まってしまう問題は v2.1.222 で直っているので、ここで固まる場合は版を上げる。版の上げ方と自動更新の止め方はClaude Codeのアップデート7手順にまとめてある。
手順6｜ファイアウォールで開けるホストを決める
情シスに申請する段になったら、必要なホストを列挙する。コンテナや制限の強いネットワークでは、ここが抜けていると一部の機能だけが静かに死ぬ。
通信が必須になるホスト
| ホスト | 何に使うか |
|---|---|
api.anthropic.com |
Claude APIへのリクエスト、WebFetchのドメイン安全性チェック、機能フラグの取得、テレメトリの送信 |
claude.ai |
claude.aiアカウントの認証 |
claude.com |
claude.aiのサインインがブラウザで開くページ。CLIからの事前承認済みWebFetchもこのホストに届く |
platform.claude.com |
Anthropic Consoleアカウントの認証。claude.aiアカウントのOAuthトークンの交換・更新・失効もここを通る |
downloads.claude.ai |
プラグインの実行ファイル配布、ネイティブインストーラーと自動更新、更新版の確認 |
registry.npmjs.org |
プラグインのインストール、npx 起動のMCPサーバー、npm/bunでClaude Code自体を入れる場合のレジストリ |
github.com |
プラグインマーケットプレイスとプラグインのクローン |
初回セットアップの接続チェックは api.anthropic.com と platform.claude.com の2つを見ているので、この2つが閉じていればサインイン画面にすら到達しない。まずここを開けてもらう。
用途が限られるホスト
mcp-proxy.anthropic.com：claude.ai由来のMCPコネクタ。使わないならENABLE_CLAUDEAI_MCP_SERVERS=falseかdisableClaudeAiConnectors設定で取得自体を止められる。storage.googleapis.com：/pluginに出るプラグインのインストール数とメタデータ。2.1.116より前の版ではネイティブインストーラーと自動更新もここを使っていた。bridge.claudeusercontent.com：Claude in ChromeのWebSocketブリッジ。*.frame.claudeusercontent.com：アーティファクトの内容取得。"enableArtifact": falseかCLAUDE_CODE_DISABLE_ARTIFACT=1で機能ごと止めればこの要件も消える。raw.githubusercontent.com：/release-notesの更新履歴。formulae.brew.sh：Homebrew導入時の更新確認。他の導入方法では使わない。code.claude.com：組み込みのドキュメント参照。ここを塞いでもドキュメント検索が効かなくなるだけで、他の動作には影響しない。
テレメトリ用の2つのDatadogホスト（http-intake.logs.us5.datadoghq.com と browser-intake-us5-datadoghq.com）は任意で、CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC を設定すれば両方止まる。許可リストを確定する前に、ここを止める方針かどうかを先に決めておくと申請が1往復減る。
なお npm導入なら downloads.claude.ai のネイティブインストーラー・自動更新用途は不要になるが、代わりに registry.npmjs.org（社内ミラーがあればそちら）が要る。導入方法によって必要なホストが変わるので、配布方法を決めてから申請する。
IP許可リストを併用している場合
組織でClaudeへのIP許可リストを有効にしているなら、bridge.claudeusercontent.com を claude.ai や api.anthropic.com と同じプロキシ出口に通す。Zscalerのアプリセグメントを揃える、Netskopeのステアリングポリシーを揃える、といった形だ。Anthropic側はこのホストへの接続を、到着元のアドレスで組織の許可リストと突き合わせる。別の出口アドレスから出ていると、他の機能は動くのにClaude in Chromeだけが繋がらない、という分かりにくい状態になる。
GitHub Enterprise CloudでIP制限をかけている場合は、インストール済みGitHub Appに対するIP許可リストの継承を有効にする必要がある。ここは開発環境の構成そのものに関わるので、コンテナ側で完結させたいならClaude Code Dev Container安全導入の構成と合わせて検討するとよい。
手順7｜シェルではなく設定ファイルに置く
ここまでの設定を .bashrc や .zshrc に書いて終わりにすると、背景セッションで効かないことがある。理由は実行の形が違うからだ。
背景エージェントは別のプロセスがホストしている
背景エージェントは、それを起動した端末の中では走らない。ユーザーごとのスーパーバイザープロセスが必要に応じて起動し、シェルより長く生き残り、claude agents、--bg、/background のセッションをすべてホストする。
このスーパーバイザーはすべての端末で共有される1つのプロセスで、最初にそれを起動したシェルの環境を引き継ぐ。OSがサービスとして入れたスーパーバイザーに至っては、シェルの環境をまったく受け取らない。つまりプロキシやCAのパスをシェルだけでexportしていると、たまたまそのシェルがスーパーバイザーを起動したときだけ効き、別のシェルが起動したときは黙って効かない。この「日によって通ったり通らなかったりする」挙動の正体がこれだ。
env ブロックに書く
対処は単純で、同じ変数を ~/.claude/settings.json の env ブロック、または管理設定に書く。この記事で挙げた変数はすべてそこに置ける。
{
"env": {
"HTTPS_PROXY": "http://proxy.example.com:8080",
"NO_PROXY": "localhost,.internal.example.com",
"NODE_EXTRA_CA_CERTS": "/etc/ssl/certs/corp-ca.pem"
}
}
設定ファイルに書いたものだけが、すべてのマシンのすべての背景セッションに届く。
ここで1つ注意がある。リポジトリに共有する .claude/settings.json に書いた場合、env の値の大半は各自がそのフォルダを信頼するまで適用されない。「リポジトリに入れておけば全員に配れる」と考えると、信頼していないメンバーの端末だけ設定が効かない状態になる。プロキシやCAのように全員に確実に効かせたい設定は、個人の ~/.claude/settings.json か管理設定に置く。組織として配る場合の置き場所はClaude Code全社ガバナンスの側で整理している。
起動をラッパー経由に強制している場合
サンドボックス、ネットワーク制御、資格情報の注入のために、すべてのClaude Codeプロセスを社内のランチャー経由で起動させている組織もある。スーパーバイザーとそのワーカーは、PATH から claude を探すのではなく固定パスから起動するので、PATH の前に置いたラッパーは背景エージェントを素通りする。
この場合は processWrapper 設定を使う。同等の環境変数 CLAUDE_CODE_PROCESS_WRAPPER もあり、両方設定されている場合は環境変数が優先される。すでに走っているスーパーバイザーは起動時の構成を持ち続けるので、設定を配ったあとに claude daemon stop --any を実行して、次の claude agents や --bg が新しい構成でスーパーバイザーを起こすようにする。サービスとしてインストールされている場合は --any 無しの claude daemon stop でよい。
ストリーミングが途中で切れるときの読み分け
設定が正しくても、プロキシが応答の途中に手を入れていると別の症状が出る。原因がプロキシ側にあると分かりやすいメッセージが3つあるので、押さえておく。
接続が応答の途中で落ちる｜Socket is closed
Socket is closed は、ストリーミング応答を運んでいた接続が、応答の到着中に閉じられたという意味だ。もっとも多い原因は、Windowsの社内プロキシが確立済みのトンネルを応答の途中で落とすこと。v2.1.214以降はこの失敗もリトライされるので、まず claude update で版を上げ、それでも同じプロキシの背後で落ち続けるなら手順1からやり直す。
応答が空のまま終わる｜ストリーミングの変換
Streaming response ended before any complete data was received. Retrying without streaming. は、ストリーミング応答が使えるデータを1つも返さずに終わったという警告だ。対話セッションで1セッションに1回だけ出る。原因は、間にいるプロキシやゲートウェイがストリーミングの応答ボディを消費または変換していること。プロキシ側で、ストリーミングのボディとヘッダーを無加工で通す設定にしてもらう。
非ストリーミングの経路だけが壊れている場合
HTTP 200 なのに中身がAPIの応答でない場合の対処は手順1で触れたとおりだが、もしゲートウェイの非ストリーミング経路だけが壊れているなら、CLAUDE_CODE_DISABLE_NONSTREAMING_FALLBACK=1 を設定することで、途中で失敗したリクエストがこのフォールバックではなく通常のリトライ経路へ回るようになる。ただしストリーミングのエンドポイント自体が 404 を返す場合は、それでもフォールバックする。
応答が返ってくるのに遅い、という症状はプロキシとは別の原因であることが多い。その場合はClaude Codeの応答が遅いときの原因切り分けの側を見てほしい。
よくある質問
Claude CodeはSOCKSプロキシに対応していますか？
対応していません。公式ドキュメントに「Claude Code does not support SOCKS proxies」と明記されています。社内の出口がSOCKSしかない場合は、HTTP/HTTPSプロキシの経路を用意してもらうか、その認証方式に対応したLLMゲートウェイを挟む方向になります。
NODE_TLS_REJECT_UNAUTHORIZED=0 で通ったのですが、このまま運用してよいですか？
避けてください。公式ドキュメントはSSL証明書エラーの対処の項で、この設定は証明書の検証を完全に無効化するため設定しないように、と明示しています。TLS傍受環境こそ検証が要る場所なので、NODE_EXTRA_CA_CERTS に組織のCAバンドルのパスを渡す形にしてください。
プロキシの設定を書き換えたのに反映されません
この記事で扱う環境変数は起動時に一度だけ読まれるため、走っているセッションはあとからのシェル側の変更を拾いません。Claude Codeを起動し直してください。例外はクライアント証明書と鍵で、これらは設定を適用したときと、接続レベルのエラーで失敗したあとのリトライで読み直されます。
/status に Additional CA cert(s) が出ているのに証明書エラーが続きます
この行は NODE_EXTRA_CA_CERTS のパスを表示するだけで、そのファイルが実際に読み込めたかまでは確認していません。claude --debug で起動して ~/.claude/debug/<session-id>.txt を開き、CA certs: Appended extra certificates from NODE_EXTRA_CA_CERTS の行が出ているか、Failed to read や Failed to load になっていないかを確認してください。
端末では動くのに、背景エージェントだけ繋がりません
背景セッションをホストするスーパーバイザーは、最初にそれを起動したシェルの環境を引き継ぐ共有プロセスで、OSがサービスとして起動した場合はシェルの環境をまったく受け取りません。同じ変数を ~/.claude/settings.json の env ブロックか管理設定へ移してください。
ネットワークは開いているのに起動時の接続チェックが失敗します
起動時チェックは api.anthropic.com と platform.claude.com の2つを見て、各プローブに10秒を与えます。プロキシ経由で失敗した場合は、どの環境変数がそのプロキシを設定したのかがメッセージに出るので、まずそこを確認してください。https:// スキームのプロキシURLでこのチェックが止まる問題は v2.1.222 で直っています。ネットワークが開いていて失敗が続く場合は、Claude Codeが対応している国・地域の外にいる可能性もあります。
ファイアウォールで許可するホストは全部必要ですか？
必須は api.anthropic.com と、認証に使うホスト（claude.aiアカウントなら claude.ai、claude.com、platform.claude.com）です。プラグイン、アーティファクト、Claude in Chrome、テレメトリなどは機能ごとに無効化でき、無効化すれば対応するホストも不要になります。導入方法によっても必要なホストが変わる（npm導入なら registry.npmjs.org、Homebrew導入なら formulae.brew.sh）ので、配布方法を先に決めてから申請してください。
npmで入れたらOSに配布済みのCAが効きません
OSの証明書ストアを読むには tls.getCACertificates を持つランタイムが必要で、npm導入の場合は Node 22.15以降が要ります。それより古いNodeでは、同梱のCA集合と NODE_EXTRA_CA_CERTS だけが効きます。Nodeを上げるか、NODE_EXTRA_CA_CERTS でCAバンドルのパスを直接渡してください。
あわせて読みたい
運営元 Uravation よりこの事例を自社の業務で試す場合のテーマ選定・評価・本番移行の確認項目を、無料のチェックリストにまとめています。 Claude Code業務自動化PoCチェックリストを受け取る（無料）
参考・出典
- Anthropic「Enterprise network configuration（Claude Code Docs）」（プロキシ変数、
CLAUDE_CODE_CERT_STORE、NODE_EXTRA_CA_CERTS、mTLS、claude --debugと/statusの確認行、許可が必要なホスト一覧、背景エージェントへの設定反映、processWrapper） - Anthropic「Error reference（Claude Code Docs）」（
Unable to connect to APIの各コード、Unable to connect to Anthropic servicesの10秒プローブ、SSL証明書エラー、Socket is closed、HTTP 200 の不正応答、プロキシのトンネル拒否ステータス） - Anthropic「Settings（Claude Code Docs）」（
envブロックの位置づけと、リポジトリ共有ファイルのenvが各自の信頼を待つこと） - Node.js「Command-line API —
NODE_EXTRA_CA_CERTS」 - Node.js「TLS (SSL) —
tls.getCACertificates()」 - Anthropic Support「Restrict access to Claude with IP allowlisting」
- GitHub Docs「Managing allowed IP addresses for your organization」
- Anthropic「Supported countries」
