Claude Code WebFetchエラーの完全なトラブルシューティング：Unable to verify if domain問題を解決する4ステップ

レイヤー4 · WebFetchをバイパス Bash(curl:*) の代替 · または fetch-mcp / Playwright MCP server の接続 🎯 CIコンテナ / preflightが完全に通らないシナリオ · claude.aiのpreflightを完全に回避する 15分 究極のソリューション

第1層：プロキシと NO_PROXY 環境変数

これは国内ユーザーが最初に直面する最も一般的な壁です。Claude Code は標準的なプロキシ環境変数に従い、以下の優先順位で読み込みます：

https_proxy > HTTPS_PROXY > http_proxy > HTTP_PROXY

macOS / Linux の最小構成：

# ~/.zshrc または ~/.bashrc
export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
export NO_PROXY="localhost,127.0.0.1,::1,api.apiyi.com,vip.apiyi.com"

Windows PowerShell:

$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:NO_PROXY = "localhost,127.0.0.1,api.apiyi.com,vip.apiyi.com"

また、~/.claude/settings.json の env ブロックに直接記述することも可能です：

{
  "env": {
    "HTTPS_PROXY": "http://127.0.0.1:7890",
    "HTTP_PROXY": "http://127.0.0.1:7890",
    "NO_PROXY": "localhost,127.0.0.1,api.apiyi.com,vip.apiyi.com"
  }
}

⚠️ 重要な詳細: NO_PROXY には APIYI の中継ドメイン（api.apiyi.com / vip.apiyi.com）を必ず追加してください！そうしないと、Claude Code のモデル呼び出しがプロキシを経由してしまい、低速になるだけでなく、プロキシノードによって傍受される可能性があります。API 呼び出しは NO_PROXY で APIYI に直結させ、WebFetch のプリフライト（preflight）はプロキシ経由で claude.ai にアクセスさせるという、2つの経路を分ける構成が最も安定します。

基本認証プロキシ（企業プロキシで一般的）：

export HTTPS_PROXY=http://username:[email protected]:8080

注意: Claude Code は SOCKS プロキシをサポートしていません。プロキシが SOCKS モードのみの場合は、privoxy や v2ray を使用して SOCKS を HTTP に変換してください。

第2層：権限の事前承認 WebFetch(domain:xxx)

プリフライトは通るものの、Claude Code が毎回「このドメインの取得を許可しますか？」と尋ねてくる場合があります。よく使うドメインを permissions.allow に追加すれば、Claude は二度と質問してきません：

{
  "permissions": {
    "allow": [
      "WebFetch(domain:www.weather.com.cn)",
      "WebFetch(domain:github.com)",
      "WebFetch(domain:developer.mozilla.org)",
      "WebFetch(domain:docs.python.org)"
    ],
    "ask": [
      "WebFetch"
    ]
  }
}

ルール構文のクイックリファレンス：

🎯 管理アドバイス: 企業環境では、managed-settings.json を使用して取得許可ドメインをホワイトリスト化することを推奨します。macOS なら /Library/Application Support/ClaudeCode/managed-settings.json、Linux なら /etc/claude-code/managed-settings.json に配置し、allowManagedPermissionRulesOnly: true を設定することで、全開発者に強制適用できます。APIYI apiyi.com を通じて Claude API を利用する開発チームも、同じルールセットを使うことで、Claude Code とバックエンドの API 呼び出しにおける権限ポリシーを統一できます。

第3層：企業用 CA 証明書と TLS 傍受

Zscaler、CrowdStrike、Cato Networks などの TLS 傍受型セキュリティ製品を導入している企業環境では、HTTPS 証明書が再発行されるため、Claude Code の Node.js ランタイムで UNABLE_TO_GET_ISSUER_CERT などの SSL エラーが発生します。

解決策: 企業のルート CA 証明書をエクスポートし、それを指定します：

export NODE_EXTRA_CA_CERTS=/path/to/company-root-ca.pem

または ~/.claude/settings.json に記述します：

{
  "env": {
    "NODE_EXTRA_CA_CERTS": "/Users/you/certs/company-root-ca.pem",
    "CLAUDE_CODE_CERT_STORE": "bundled,system"
  }
}

CLAUDE_CODE_CERT_STORE の設定値：

mTLS 双方向認証（より厳格な企業環境）：

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"

第4層：WebFetch を回避し、Bash curl や MCP で代替する

上記3層で解決しない場合、最も確実な方法は WebFetch を使わないことです。Claude に Bash ツール経由で直接 curl を実行させるか、サードパーティの fetch MCP サーバーを導入します。

案 A：Bash で curl/wget を許可する

{
  "permissions": {
    "allow": [
      "Bash(curl:*)",
      "Bash(wget:*)"
    ]
  }
}

その後、対話の中で Claude に「www.weather.com.cn のホームページの内容を curl で取得して」と指示すれば、WebFetch をスキップして直接 Bash を実行します。この経路はプリフライトを一切トリガーしないため、対象サイトにアクセスできるプロキシ設定さえあれば問題ありません。

案 B：fetch-mcp または Playwright MCP を導入する

# サードパーティの fetch MCP サーバーをインストール
claude mcp add fetch npx -- @modelcontextprotocol/server-fetch

MCP ツールのネットワークリクエストは MCP サーバープロセス自身によって実行されるため、Claude Code のプリフライト経路を通らず、安定性が大幅に向上します。JavaScript の実行が必要な動的サイトには、Playwright MCP の方が適しています。

WebFetchトラブルシューティング手法比較マトリックス ★が多いほど適しています · どの列が最も濃い色かを確認してください

評価指標

A. プロキシ設定 HTTPS_PROXY

B. 権限の事前承認 WebFetch(domain)

C. 企業 CA NODE_EXTRA_CA_CERTS

D. WebFetchを回避する Bash curl + MCP

設定の難易度 ★★★★☆ ★★★★★ ★★☆☆☆ ★★★★☆

問題解決の幅を広げる ★★★★★ ★★☆☆☆ ★★★☆☆ ★★★★★

パフォーマンスへの影響 ★★★☆☆ ★★★★★ ★★★★☆ ★★★★☆

企業コンプライアンス ★★★☆☆ ★★★★★ ★★★★★ ★★★☆☆

国内向け最適化 ★★★★☆ ★★★☆☆ ★★☆☆☆ ★★★★★

💡 国内ユーザー向け推奨構成: A(プロキシ基盤) + B(常用ドメイン) + D(フォールバック)

Claude Code WebFetch の実戦トラブルシューティング事例

理論はここまでにして、3つのリアルなシナリオにおける完全な解決フローを見ていきましょう。

シナリオ1: 国内（中国）のMacBookで weather.com.cn を取得（スクリーンショット撮影）

現象: www.weather.com.cn を fetch すると連続して Unable to verify エラーが発生する。

トラブルシューティング手順:

# Step 1 プロキシの状態を確認
echo $HTTPS_PROXY  # http://127.0.0.1:7890 のように出力されるはず

# Step 2 claude.ai に到達可能か手動で検証
curl -I https://claude.ai/code/ -x http://127.0.0.1:7890
# 403 + cf-mitigated が返ってきたら、Cloudflare にブロックされています。Step 3 へ。
# 200 が返ってきたら、プリフライトは通過済みです。権限設定を確認してください。

# Step 3 Claude Code で別の手段に切り替える — Bash + curl を使用
# 対話の中で直接こう伝えます:
# "WebFetch は使わず、curl を使って http://www.weather.com.cn のトップページを取得して"

最終設定(~/.claude/settings.json):

{
  "env": {
    "HTTPS_PROXY": "http://127.0.0.1:7890",
    "HTTP_PROXY": "http://127.0.0.1:7890",
    "NO_PROXY": "localhost,127.0.0.1,api.apiyi.com,vip.apiyi.com"
  },
  "permissions": {
    "allow": [
      "WebFetch(domain:www.weather.com.cn)",
      "Bash(curl:*)",
      "Bash(wget:*)"
    ]
  }
}

🎯 国内での実戦ヒント: 国内ユーザーにとって最も安定する組み合わせは、「API は APIYI (apiyi.com) を利用 + WebFetch はプロキシ経由 + 必要に応じて curl にフォールバック」です。APIYI の base_url を NO_PROXY に追加することで、Claude Code の API リクエストがプロキシを経由せず、海外直結と同等の低遅延と安定性を確保できます。

シナリオ2: 企業環境 + Zscaler TLS インターセプト

現象: WebFetch で SELF_SIGNED_CERT_IN_CHAIN または UNABLE_TO_VERIFY_LEAF_SIGNATURE が発生する。

解決策:

# Step 1 IT部門から社内のルートCA証明書を取得する (.pem または .crt)
# Step 2 Claude Code がこの CA を信頼するように設定する
export NODE_EXTRA_CA_CERTS=~/certs/company-zscaler-root.pem

# Step 3 システム証明書ストアも同時に信頼する (Zscaler は通常ここに注入されています)
export CLAUDE_CODE_CERT_STORE=bundled,system

# Step 4 Claude Code を再起動

シナリオ3: Docker / CI コンテナ内でのヘッドレス実行

現象: ローカルでは動くが、CI 環境では WebFetch が100%失敗する。

原因: コンテナ内にプロキシもブラウザもなく、Cloudflare のボット対策機能が CLI クライアントを検知して接続を拒否しているため。

解決策: CI 環境では WebFetch を無効化し、Bash を強制する:

# .github/workflows/claude.yml など
env:
  CLAUDE_CODE_DISABLE_WEBFETCH: "true"  # この環境変数が有効な場合

または、--disallowedTools 起動引数を使用します:

claude --disallowedTools WebFetch --allowedTools "Bash(curl:*)"

🎯 CI 統合のアドバイス: コンテナ環境では、APIキーを APIYI (apiyi.com) の安定した中継ノードに向けることで、海外ネットワークの不安定さによる CI 失敗を防げます。GitHub Actions / GitLab CI の secrets に ANTHROPIC_BASE_URL=https://vip.apiyi.com + ANTHROPIC_API_KEY=sk-xxx を設定し、WebFetch 無効化戦略を組み合わせることで、CI 上の Claude Code タスクの安定性を 99% 以上に高めることができます。

Claude Code WebFetch エラー回避のエンジニアリングベストプラクティス

一度デモを成功させるのは簡単ですが、チーム全員が Claude Code を安定して使えるようにするには、いくつかの重要なポイントがあります。

実践1: 統一された managed-settings.json の配布

チーム全体に統一された managed-settings.json を配布し、各自が個別に設定で苦労するのを防ぎます:

{
  "env": {
    "HTTPS_PROXY": "http://corp-proxy:8080",
    "NODE_EXTRA_CA_CERTS": "/opt/company/ca.pem",
    "NO_PROXY": "*.corp.example.com,api.apiyi.com,vip.apiyi.com"
  },
  "permissions": {
    "allow": [
      "WebFetch(domain:*.corp.example.com)",
      "WebFetch(domain:github.com)",
      "WebFetch(domain:stackoverflow.com)",
      "Bash(curl:*)"
    ],
    "deny": [
      "WebFetch(domain:*)"
    ]
  },
  "allowManagedPermissionRulesOnly": true
}

ファイルの配置パス:

実践2: 3段階のフォールバック戦略

CLAUDE.md にツール使用の優先順位を明記し、Claude に順番通り試行させます:

## Webスクレイピングツールの優先順位

1. WebFetchを優先（事前承認済みのドメイン）
2. WebFetchが失敗した場合は、Bashのcurlにフォールバック
3. 動的サイトにはPlaywright MCPを使用
4. `curl -k` を使用して証明書エラーを無視することは厳禁

```markdown
この内容を CLAUDE.md に記述しておくと、ClaudeはWebFetchでエラーが発生した際に**自動的にcurlへ切り替える**ようになり、ユーザー体験が大幅に改善されます。

実践3: preflightヘルスチェックスクリプト

トラブルシューティング時にまず実行する、迅速な診断スクリプトを作成しました。

#!/bin/bash
# claude-code-doctor.sh

echo "=== 環境変数 ==="
env | grep -iE "proxy|claude_code|node_extra"

echo "=== claude.ai preflight テスト ==="
curl -sI -o /dev/null -w "HTTP %{http_code} · %{time_total}s\n" \
  https://claude.ai/code/

echo "=== api.anthropic.com テスト ==="
curl -sI -o /dev/null -w "HTTP %{http_code} · %{time_total}s\n" \
  https://api.anthropic.com/

echo "=== APIYI 中継テスト ==="
curl -sI -o /dev/null -w "HTTP %{http_code} · %{time_total}s\n" \
  https://vip.apiyi.com/

echo "=== DNS 名前解決 ==="
nslookup claude.ai

もし claude.ai/code/ が cf-mitigated レスポンスヘッダーを伴う403エラーを返す場合、典型的なCloudflareのpreflight問題です。直接レイヤー4のソリューションを適用してください。

🎯 診断のアドバイス: Claude Codeで異常が発生した際、80%の問題はこの診断スクリプトで特定可能です。中国国内のユーザーは、vip.apiyi.com をAPI中継ノードとしてチェックリストに加えることを推奨します。もしAPIYIには到達できるがAnthropicの公式サイトには到達できない場合、APIYI apiyi.com の中継を利用して作業を継続し、ネットワークの問題で開発が完全にストップする事態を回避できます。

Claude Code WebFetch エラーに関するFAQ

Q1: "enterprise security policies blocking claude.ai" というエラーが出ますが、社内でセキュリティソフトは入れていません。なぜですか？

これはAnthropic公式のエラーメッセージが不正確なためです。実際に遮断しているのは、claude.aiの手前にあるCloudflareのBot保護機能です。CloudflareがCLIプロセスをBotと識別してJS Challengeを返しますが、CLI側でそのチャレンジを完了できないためにこのエラーが表示されます。通常、会社のITポリシーとは無関係です。

Q2: APIYIの中継でWebFetchのエラーは解決できますか？

部分的に解決可能です。APIYI apiyi.com は api.anthropic.com へのAPIリクエストの中継のみを担当しており、Claude Codeのモデル対話やツール呼び出しの判断は安定して動作します。しかし、WebFetchのpreflightは claude.ai に対して行われるため(api.anthropic.comではありません)、この経路はAPIYIのカバー範囲外です。ローカルプロキシでの解決が必要です。APIはAPIYI直結、preflightはプロキシ経由という組み合わせを推奨します。

Q3: skipWebFetchPreflight という設定項目はありますか？

コミュニティで議論されていますが、2026年4月現在、公式ドキュメントには記載されていません。GitHub issue #39896 で期待される機能として言及されています。正式サポートされるまでは、**レイヤー4のソリューション(Bash curl + 許可ドメインの事前承認)**を使用してこの問題を回避することを推奨します。効果は同等で、より制御しやすいためです。

Q4: Clashのグローバルプロキシをオンにしているのに、なぜWebFetchはエラーになるのですか？

Clashのグローバルプロキシモードは、環境変数を自動設定しません。Claude CodeはNode.jsのCLIプロセスであり、HTTPS_PROXY などの環境変数を読み取るだけで、システムプロキシの設定を自動的に検知・利用することはありません。シェルプロファイルでプロキシ変数を明示的に export するか、~/.claude/settings.json の env ブロックに記述する必要があります。

Q5: WebFetchは成功しましたが、結果が不完全で内容が途中で切れています。

これはClaude Codeの max_content_tokens 制限によるものです。権限ルール内では調整できませんが、Claude APIを直接呼び出して web_fetch ツールを使用する場合（Claude Code CLI経由ではない場合）、"max_content_tokens": 100000 を設定して1ページあたりの取得量を増やすことができます。このシナリオでは、APIYI apiyi.com を通じてAPIに直結する方が柔軟性が高いため推奨されます。

Q6: WebFetchを無効にすることでエラーを完全に回避できますか？

可能です。起動時に引数を追加してください：

claude --disallowedTools WebFetch

または settings.json に以下を記述します：

{
  "permissions": {
    "deny": ["WebFetch"]
  }
}

Bash(curl:*) を許可しておけば、Claudeは自動的にcurlを使用するようになり、国内ユーザーにとってはむしろ体験が向上します。

Q7: GitHub Actions / GitLab CI で Claude Code を使う場合の設定は？

CIコンテナ内では WebFetchの無効化を強く推奨します。コンテナにはブラウザ環境がないため、preflightはほぼ確実に失敗します。同時に、APIリクエストをAPIYI apiyi.com の安定したノードに向けてください：

env:
  ANTHROPIC_BASE_URL: https://vip.apiyi.com
  ANTHROPIC_API_KEY: ${{ secrets.APIYI_KEY }}
  CLAUDE_CODE_DISALLOWED_TOOLS: "WebFetch"

Claude Code WebFetch エラーのまとめとアクションリスト

全文を振り返ると、Claude Code WebFetch エラーの本質は、Cloudflareのプリフライト（preflight）とCLIにブラウザが搭載されていないことによる設計上の制限であり、あなたのネットワークやITポリシーの問題ではありません。一言でまとめると以下の通りです。

✅ 国内ユーザー向けの鉄則: APIはAPIYI（apiyi.com）経由で直結し、ローカルプロキシはclaude.aiのプリフライトを通し、Bashのcurlをフォールバックとして使用する。これでWebFetchエラーの90%は回避可能です。

実行アクションリスト

優先度順に以下の5ステップを実行してください。

1. プロキシ設定: HTTPS_PROXY と HTTP_PROXY を設定し、APIYIのドメインを NO_PROXY に追加します。
2. ドメインの事前承認: よく取得するサイトを permissions.allow の WebFetch(domain:...) に記述します。
3. 企業用CAの処理: ZscalerやCrowdStrike環境下にある場合は、NODE_EXTRA_CA_CERTS を設定します。
4. フォールバックの準備: Bash(curl:*) を許可し、Claudeが詰まった際に自動的に切り替わるようにします。
5. ヘルスチェックスクリプト: claude-code-doctor.sh をチームのツールチェーンに組み込みます。

国内ユーザーのベストプラクティス · パス別・階層別アーキテクチャ APIパスとWebFetchパスの分離・相互に影響なし

開発者ローカル環境 Claude Code CLI NO_PROXY設定: api.apiyi.com

① APIパス APIYI 透明転送 vip.apiyi.com (直接接続)

② Preflightパス ローカルプロキシ 127.0.0.1:7890

③ フォールバック Bash(curl:*) ターゲットサイトに直接接続

Anthropic API api.anthropic.com モデル推論 + ツール決定

claude.ai/code/ ドメイン検証エンドポイント (Cloudflare 保護)

ターゲットサイト weather.com.cnなど 直接接続（プリフライト不要）