Claude Codeのartifact取得でproxy refusedが出る原因と対処
artifactを読むとき「The proxy refused the connection」と出る原因を、HTTP 407・403・502とunreadable replyの状態コード別に切り分け、直し方を示します。
Claude Codeでartifactを読もうとしてartifact content fetch failed (proxy refused the connection: HTTP 407)のような行が出たら、原因はプロキシ側の返答にあります。末尾のHTTPステータスが、直す場所を決めます。
結論を先に書くと、407は資格情報の不足、403は*.frame.claudeusercontent.comへの通路を拒否されている状態、502などはプロキシ自身の事情です。unreadable replyと出た場合は、プロキシのアドレスに別のものが応答しています。
状態コード別の直し先
- 407: プロキシURLに資格情報を入れる
- 403: プロキシ管理者に
*.frame.claudeusercontent.comの許可を頼む - 502など: プロキシのログで理由を調べる
- unreadable reply: そのアドレスがHTTPプロキシか確かめる
このエラーはどこで出るのか
「The proxy refused the connection」は、HTTPS_PROXYなどのプロキシ変数を設定した環境で、Claude Codeがartifactを読むときに出るエラーです。artifactの本文は*.frame.claudeusercontent.comから取得されます。Claude CodeはまずプロキシへCONNECTリクエストを送り、このホストへのトンネルを開くよう頼みます。プロキシが断ると、ホストには何も届きません。
ここで押さえておきたいのは、CONNECTへの返答がプロキシのものだという点です。目的のホストは一度も答えていません。だから、ステータスが指す先はartifactの中身でもClaudeのアカウントでもなく、プロキシの設定です。
出力は次の3種類が確認できます。
artifact content fetch failed (proxy refused the connection: HTTP 407)
artifact content fetch failed (proxy refused the connection: HTTP 403)
the proxy refused the connection to the artifact's content host (HTTP 502)v2.1.238より前のClaude Codeは、トンネルを断られた状況を汎用のネットワークエラーとして報告していました。古いバージョンでは文面が違うため、同じ原因でもこの見出しの語では見つかりません。
状態コード別の直し方
HTTP 407: 資格情報がプロキシに届いていない
407は、プロキシが認証を要求したのに、必要な資格情報を受け取れなかった状態です。Basic認証で足りるプロキシなら、URLに資格情報を含めて渡します。
export HTTPS_PROXY=http://username:password@proxy.example.com:8080パスワードをスクリプトに書き込む運用は避け、環境変数や安全な資格情報の保管先から渡す形にします。NTLMやKerberosのような高度な認証が必要なプロキシは、LLMゲートウェイサービスを検討する対象です。SOCKSプロキシにも対応していないので、アドレスがSOCKSなら別の経路を用意します。
APIへの接続は通るのに、artifactだけ407になる場合も同じ確認から始めます。設定した変数の値を/statusの「Proxy」の行で見ると、実際に使われているURLがわかります。
HTTP 403: artifactのホストだけ拒否されている
403は、プロキシがartifactの配信ホストへのトンネルを拒否している状態です。クライアント側の設定では直らず、プロキシを運用している人に*.frame.claudeusercontent.comの許可を頼みます。
許可リストに載せるべきホストは、ネットワーク要件の表に整理されています。artifactの内容を読む通信は*.frame.claudeusercontent.com宛てで、Chromeの拡張機能が使うbridge.claudeusercontent.comとは別のホストです。
HTTP 502などその他: プロキシ側の事情
407と403以外の状態は、プロキシが自分の理由でトンネルを開けなかったことを示します。たとえば、プロキシからホストへ届かなかった場合です。Claude Code側で直せるものはなく、プロキシのログでそのステータスの理由を調べます。
unreadable reply: HTTPプロキシではない相手が答えている
ステータスの代わりにunreadable replyと出る場合、プロキシ変数のアドレスにいる相手が、HTTPのステータス行を返していません。ポート番号の取り違えや、別のサービスが同じアドレスを使っている状況が候補です。変数に入れたアドレスが、HTTPプロキシのものかを確かめます。
まず試す切り分けコマンド
状態コードを見る前に、プロキシ設定そのものが正しいかを確かめます。公式の手順は、Claude Codeを起動するのと同じシェルから、自分のプロキシURLを指定してcurlを実行する方法です。
curl -x http://proxy.example.com:8080 \
-I https://api.anthropic.comWindowsのPowerShellではcurl.exeを使います。この確認が同じ形で失敗するなら、artifactではなくプロキシ設定の誤りなので、先にそちらを直します。成功するなら、拒否はartifactのホスト固有のものです。
プロキシURLの値そのものは、起動時に解釈できるかどうかだけ検査されます。http://の付け忘れなどで解釈できないと、Claude Codeは変数名を示して起動を止めます。それ以外のアドレスや証明書パスの誤りは、後続の通信で初めてエラーになります。設定が読み込まれたかはclaude --debugのログで確かめられ、実際に使われているプロキシURLは/statusの「Proxy」の行に出ます。
プロキシ設定が原因かartifact固有かの切り分け
- Qcurlでapi.anthropic.comまで通るか?答えがいいえ答えがはい
プロキシのアドレス、資格情報、許可ホストを見直します。artifact以前の問題です。
- Qエラー末尾の状態コードは407以外か?答えがいいえ(407)答えがはい
資格情報をプロキシのURLに入れて、もう一度試します。
403・502・unreadable replyはそれぞれ該当の節へ
403は許可の依頼、502などはプロキシのログ、unreadable replyはアドレスの確認が次の一手です。
直接つながる環境ならNO_PROXYで迂回する
ネットワークがartifactのホストへ直接の接続を許しているなら、プロキシを通さない選択肢があります。NO_PROXYに.frame.claudeusercontent.comを追加します。
export NO_PROXY="localhost,.frame.claudeusercontent.com"書き方は、スペース区切りでもカンマ区切りでも通ります。ここで注意したいのは、エントリを広げすぎないことです。.claudeusercontent.comと書くと、bridge.claudeusercontent.comまでプロキシを迂回してしまいます。組織がIPアドレスの許可リストを使っている場合、bridge.claudeusercontent.comはプロキシ経由のままにしておく必要があります。
artifactが不要なら取得そのものを止める
artifactを使わない環境では、この通信自体を無くせます。ネットワーク要件の表によれば、*.frame.claudeusercontent.comが必要になるのは、artifactツールが利用可能なアカウントで、Claudeがartifactを開くときです。次のどちらかでツールを切ると、この要件は不要になります。
| 方法 | 設定 |
|---|---|
| 設定ファイル | 設定"enableArtifact": false |
| 環境変数 | 設定CLAUDE_CODE_DISABLE_ARTIFACT=1 |
環境変数か--settingsのファイル、または管理者の管理設定で切った場合、どの設定ファイルからも再び有効にはできません。プロジェクトの.claude/settings.jsonや.claude/settings.local.jsonの"enableArtifact": falseが効くのは、v2.1.242以降です。
似て見える別の症状との見分け方
プロキシまわりのメッセージは複数あり、このエラーと取り違えやすいものがあります。
Artifacts need a claude.ai loginは、プロキシではなく認証の問題です。/loginで「Claude account with subscription」を選びます。- クラウドセッションで
HTTP 403とx-deny-reason: host_not_allowedが出る場合は、環境のネットワークポリシーによるブロックです。宛先の証明書と食い違う証明書が見えることもあり、これはクラウド側のプロキシが接続を終端した印です。ローカルCLIのプロキシとは別の仕組みで、対処は環境の「Network access」で許可ドメインを足す側になります。 Couldn't connect through your proxy (ERR_PROXY_TUNNEL)は、プロキシがトンネルを拒否したことを示す別のネットワークエラー表示です。資格情報とホストの許可を確かめる点は共通します。- そもそもartifactを使えない構成もあります。APIキーやゲートウェイ、BedrockやVertex、Foundryでは公開できません。
プロキシ経由の全般的な設定は、Claude Codeのプロキシ設定の手順にまとめています。接続拒否が別の宛先から来ている場合は、Connection refusedの切り分けも見てください。artifactがそもそも開かない、公開できないといった症状は、Remote Controlでartifactが開かない原因と公開できない原因で扱っています。
ブラウザで見るときの通信は別
ターミナルでClaude Codeがartifactを読む通信と、ブラウザでartifactのページを開く通信は、別の経路です。claude.aiのビューアーは、各artifactをサンドボックス化された*.claudeusercontent.comのオリジンから読み込みます。組織が外向きの通信を制限している場合は、claude.aiと並べてこのドメインも許可します。
artifactがGoogle Fontsやライブラリを読み込む場合は、fonts.googleapis.comやcdnjs.cloudflare.comへの通信も別に発生します。
まとめ
APIは通るのにartifactだけ失敗するなら、拒否されているのはartifact用のホストだけです。クライアントの設定を探し回るより、プロキシ側の認証と許可リストを疑うほうが近道で、403なら管理者への依頼が最短です。
直接つなげる環境では、NO_PROXYに.frame.claudeusercontent.comだけを足す手があります。artifactを使わないなら、enableArtifactかCLAUDE_CODE_DISABLE_ARTIFACT=1で通信そのものを止められます。