T-CREATOR

MCP サーバー 接続失敗・タイムアウトを一発解決：TLS、プロキシ、DNS、FW の診断チェックリス

MCP サーバー 接続失敗・タイムアウトを一発解決：TLS、プロキシ、DNS、FW の診断チェックリス

MCP(Model Context Protocol)サーバーへの接続が突然失敗したり、タイムアウトが頻発したりする経験はありませんか。原因がわからず何時間も調査に費やしてしまうことは、開発者にとって非常にストレスフルです。 本記事では、TLS・プロキシ・DNS・ファイアウォールなどのネットワーク層で発生しうる接続問題を体系的に診断し、迅速に解決するためのチェックリストをご紹介します。

背景

MCP サーバーは、AI モデルと外部システムを連携させるための重要なインターフェースですが、その接続は複数のネットワーク層を経由します。 クライアントからサーバーまでのデータ通信には、DNS による名前解決、TLS による暗号化、プロキシによる中継、ファイアウォールによるアクセス制御など、さまざまな要素が関与しているのです。

以下の図は、MCP クライアントからサーバーまでの基本的な通信フローを示しています。

mermaidflowchart TD
  client["MCP クライアント"] -->|1. DNS 問い合わせ| dns["DNS サーバー"]
  dns -->|2. IP アドレス応答| client
  client -->|3. プロキシ経由| proxy["プロキシサーバー"]
  proxy -->|4. FW 通過| firewall["ファイアウォール"]
  firewall -->|5. TLS ハンドシェイク| tls["TLS レイヤー"]
  tls -->|6. 暗号化通信| server["MCP サーバー"]

図で理解できる要点:

  • 接続には DNS → プロキシ → FW → TLS の順に複数の関門がある
  • それぞれの層で異なる種類のエラーが発生しうる
  • 問題の切り分けには、各層を順番に診断することが重要

課題

MCP サーバーへの接続が失敗する際、エラーメッセージが抽象的で原因特定が困難なケースが多々あります。 典型的な問題として、以下のような症状が挙げられます。

#症状典型的なエラーメッセージ例
1タイムアウトが頻発するError: ETIMEDOUT - Connection timed out
2SSL/TLS ハンドシェイク失敗Error: SSL certificate problem: unable to get local issuer certificate
3DNS 解決ができないError: ENOTFOUND - DNS lookup failed for host
4プロキシ経由で接続できないError: ECONNREFUSED - Proxy connection refused
5ファイアウォールでブロックされるError: ECONNRESET - Connection reset by peer

これらの問題は、ネットワーク環境や設定によって発生タイミングや頻度が異なるため、一律の対処法では解決できません。 また、複数の要因が重なって問題が起きることも少なくないのです。

以下の状態遷移図は、接続失敗時に陥りやすい診断ループを示しています。

mermaidstateDiagram-v2
  [*] --> connecting: 接続試行
  connecting --> failed: タイムアウト/エラー
  failed --> retrying: リトライ
  retrying --> connecting
  retrying --> investigation: 何度も失敗
  investigation --> layer_check: 原因層の特定
  layer_check --> resolution: 診断成功
  resolution --> [*]
  layer_check --> investigation: 原因不明

図で理解できる要点:

  • 原因を特定せずにリトライを繰り返すと時間を浪費する
  • 体系的な診断(layer_check)により、早期に原因層を特定できる
  • 一度診断パターンを習得すれば、次回以降の解決が迅速になる

解決策

接続問題を効率的に解決するためには、各ネットワーク層を順番に診断するアプローチが有効です。 本セクションでは、TLS・プロキシ・DNS・ファイアウォールの 4 つの層について、診断手順と解決方法を体系的に整理します。

診断フローの全体像

まず、どの層から診断を始めるべきかを判断するために、以下の診断フローチャートを参考にしてください。

mermaidflowchart TD
  start["接続エラー発生"] --> dns_check{"DNS 解決<br/>できる?"}
  dns_check -->|NO| dns_fix["DNS 設定を確認"]
  dns_check -->|YES| proxy_check{"プロキシ<br/>経由?"}
  proxy_check -->|YES| proxy_fix["プロキシ設定を確認"]
  proxy_check -->|NO| fw_check{"FW でブロック<br/>されている?"}
  fw_check -->|YES| fw_fix["FW ルールを確認"]
  fw_check -->|NO| tls_check{"TLS エラー<br/>発生?"}
  tls_check -->|YES| tls_fix["証明書・TLS 設定を確認"]
  tls_check -->|NO| other["その他の原因を調査"]
  dns_fix --> done["解決"]
  proxy_fix --> done
  fw_fix --> done
  tls_fix --> done
  other --> done

図で理解できる要点:

  • まず DNS 解決の成否を確認することで、最も基本的な問題を排除
  • プロキシやファイアウォールの有無を順次チェック
  • 最後に TLS レイヤーの検証を行うことで、原因を絞り込める

DNS 診断チェックリスト

DNS(Domain Name System)は、ホスト名を IP アドレスに変換する仕組みです。 DNS の解決に失敗すると、そもそも接続先のサーバーに到達できません。

DNS 解決の確認コマンド

以下のコマンドで、MCP サーバーのホスト名が正しく解決されるかを確認できます。

bash# nslookup コマンドで DNS 解決を確認
nslookup mcp.example.com

このコマンドの目的: ホスト名が正しく IP アドレスに変換されるかを検証します。

正常な場合の出力例を示します。

yamlServer:  192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
Name:    mcp.example.com
Address: 203.0.113.45

エラーが発生する場合は、以下のような出力になります。

arduino** server can't find mcp.example.com: NXDOMAIN

エラーコード: NXDOMAIN エラーメッセージ: server can't find mcp.example.com: NXDOMAIN 発生条件: ホスト名が DNS サーバーに登録されていない、または DNS サーバーにアクセスできない

DNS 設定の診断手順

#確認項目コマンド期待される結果
1DNS サーバーの疎通確認ping 8.8.8.8パケットが正常に応答
2ホスト名解決の確認nslookup mcp.example.comIP アドレスが返される
3DNS キャッシュのクリアsudo dscacheutil -flushcache (macOS)キャッシュがクリアされる
4代替 DNS サーバーでの確認nslookup mcp.example.com 8.8.8.8Google DNS で解決できるか

DNS 問題の解決方法

  1. /etc/hosts ファイルに直接エントリを追加 (一時的な対処)
bash# /etc/hosts を編集
sudo nano /etc/hosts

ファイル内に以下のような行を追加します。

203.0.113.45  mcp.example.com

この設定の意図: DNS サーバーを経由せず、直接 IP アドレスを指定して名前解決をバイパスします。

  1. DNS サーバーの変更

macOS の場合、システム環境設定から DNS サーバーを変更できます。

bash# ネットワーク設定で DNS を変更(macOS の例)
# システム環境設定 → ネットワーク → 詳細 → DNS
# 8.8.8.8, 8.8.4.4 (Google DNS) を追加
  1. DNS キャッシュのクリア
bash# macOS の場合
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux の場合
sudo systemd-resolve --flush-caches

このコマンドの効果: 古い DNS キャッシュをクリアし、最新の名前解決情報を取得できます。

TLS 診断チェックリスト

TLS(Transport Layer Security)は、通信を暗号化し、サーバーの正当性を検証するためのプロトコルです。 TLS ハンドシェイクが失敗すると、暗号化通信が確立できません。

TLS 接続の確認コマンド

以下のコマンドで、TLS ハンドシェイクが成功するかを確認できます。

bash# OpenSSL コマンドで TLS 接続を確認
openssl s_client -connect mcp.example.com:443 -servername mcp.example.com

このコマンドの目的: サーバー証明書の検証や TLS バージョン、暗号スイートの確認を行います。

正常な場合の出力例(一部抜粋)を示します。

yaml---
Certificate chain
 0 s:CN = mcp.example.com
   i:C = US, O = Let's Encrypt, CN = R3
---
SSL handshake has read 3456 bytes and written 789 bytes
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
---
Verify return code: 0 (ok)

エラーが発生する場合の出力例です。

yamlverify error:num=20:unable to get local issuer certificate
verify return:1
verify error:num=21:unable to verify the first certificate
verify return:1
---
SSL handshake has read 2345 bytes and written 567 bytes
---
Verify return code: 21 (unable to verify the first certificate)

エラーコード: verify return code: 21 エラーメッセージ: unable to verify the first certificate 発生条件: サーバー証明書のチェーンが不完全、またはルート証明書が信頼ストアに存在しない

TLS 設定の診断手順

#確認項目コマンド期待される結果
1サーバー証明書の有効期限openssl s_client -connect mcp.example.com:443 | openssl x509 -noout -dates有効期限内であること
2証明書チェーンの完全性openssl s_client -connect mcp.example.com:443 -showcerts中間証明書が含まれていること
3TLS バージョンの確認openssl s_client -connect mcp.example.com:443 -tls1_2TLS 1.2 以上がサポートされていること
4暗号スイートの互換性nmap --script ssl-enum-ciphers -p 443 mcp.example.comクライアントと共通の暗号スイートが存在すること

TLS 問題の解決方法

  1. 証明書の検証をスキップする(開発環境のみ)

Node.js の環境変数で証明書検証を無効化できますが、本番環境では絶対に使用しないでください。

bash# 環境変数で証明書検証をスキップ(開発環境のみ)
export NODE_TLS_REJECT_UNAUTHORIZED=0

この設定の注意点: セキュリティリスクが高いため、開発・テスト環境でのみ使用し、本番環境では必ず証明書を正しく設定してください。

  1. カスタム CA 証明書を信頼ストアに追加

自己署名証明書や社内 CA を使用している場合、クライアント側で証明書を信頼する必要があります。

bash# macOS でカスタム CA 証明書をキーチェーンに追加
sudo security add-trusted-cert -d -r trustRoot \
  -k /Library/Keychains/System.keychain ca-certificate.crt

このコマンドの効果: カスタム CA 証明書をシステムの信頼ストアに追加し、証明書検証エラーを回避します。

  1. Node.js で CA 証明書を明示的に指定

プログラム内で証明書を指定することもできます。

javascript// Node.js で CA 証明書を指定する設定
const https = require('https');
const fs = require('fs');

// CA 証明書ファイルを読み込む
const ca = fs.readFileSync('/path/to/ca-certificate.crt');

次に、HTTPS エージェントを作成し、CA 証明書を設定します。

javascript// HTTPS エージェントの作成
const agent = new https.Agent({
  ca: ca,
  // 証明書検証を有効にする
  rejectUnauthorized: true,
});

最後に、エージェントを使用してリクエストを送信します。

javascript// エージェントを使用してリクエスト
const options = {
  hostname: 'mcp.example.com',
  port: 443,
  path: '/api',
  method: 'GET',
  agent: agent,
};

https
  .request(options, (res) => {
    console.log('接続成功:', res.statusCode);
  })
  .end();

このコードの意図: カスタム CA 証明書を使用して、自己署名証明書や社内 CA による TLS 接続を確立します。

プロキシ診断チェックリスト

企業ネットワーク内では、HTTP/HTTPS 通信がプロキシサーバーを経由することが一般的です。 プロキシ設定が正しくないと、外部サーバーへの接続ができません。

プロキシ設定の確認方法

まず、現在の環境にプロキシ設定が存在するかを確認します。

bash# 環境変数でプロキシ設定を確認
echo $HTTP_PROXY
echo $HTTPS_PROXY
echo $NO_PROXY

このコマンドの目的: シェル環境にプロキシ設定が存在するかを確認します。

出力例(プロキシが設定されている場合):

csharphttp://proxy.company.com:8080
https://proxy.company.com:8080
localhost,127.0.0.1,.internal

プロキシ経由の接続確認

プロキシ経由で MCP サーバーに接続できるかを curl コマンドで確認できます。

bash# プロキシ経由で接続確認
curl -x http://proxy.company.com:8080 https://mcp.example.com

このコマンドの期待動作: プロキシを経由して正常にレスポンスが返されます。

エラーが発生する場合の出力例です。

vbnetcurl: (7) Failed to connect to proxy.company.com port 8080: Connection refused

エラーコード: (7) Failed to connect エラーメッセージ: Connection refused 発生条件: プロキシサーバーが起動していない、または到達できない

プロキシ設定の診断手順

#確認項目コマンド期待される結果
1プロキシサーバーの疎通確認curl -I -x http:​/​​/​proxy.company.com:8080 http:​/​​/​example.comHTTP 200 が返される
2プロキシ認証の確認curl -U user:pass -x http:​/​​/​proxy.company.com:8080 http:​/​​/​example.com認証が成功する
3NO_PROXY 設定の確認echo $NO_PROXY除外ホストが正しく設定されている
4アプリケーションのプロキシ設定環境変数またはアプリ設定ファイルプロキシが正しく参照されている

プロキシ問題の解決方法

  1. 環境変数でプロキシを設定

シェルの設定ファイルにプロキシ情報を追加します。

bash# .bashrc または .zshrc に追加
export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080
export NO_PROXY=localhost,127.0.0.1,.internal

この設定の効果: すべてのコマンドラインツールがプロキシを経由するようになります。

設定を反映させるために、シェルを再読み込みします。

bash# 設定を反映
source ~/.bashrc  # または source ~/.zshrc
  1. Node.js アプリケーションでプロキシを設定

Node.js の https-proxy-agent パッケージを使用すると、プロキシ経由の HTTPS 接続が可能になります。

bash# https-proxy-agent パッケージをインストール
yarn add https-proxy-agent

次に、プロキシエージェントを作成します。

javascript// プロキシエージェントの作成
const HttpsProxyAgent = require('https-proxy-agent');

// プロキシ URL を指定
const proxyUrl = 'http://proxy.company.com:8080';
const agent = new HttpsProxyAgent(proxyUrl);

エージェントを使用してリクエストを送信します。

javascript// プロキシ経由でリクエストを送信
const https = require('https');

const options = {
  hostname: 'mcp.example.com',
  port: 443,
  path: '/api',
  method: 'GET',
  agent: agent,
};

https
  .request(options, (res) => {
    console.log('プロキシ経由で接続成功:', res.statusCode);
  })
  .end();

このコードの意図: Node.js アプリケーションでプロキシ経由の HTTPS 接続を確立します。

  1. プロキシ認証が必要な場合

プロキシがユーザー名とパスワードによる認証を要求する場合、以下のように設定します。

bash# 認証付きプロキシの設定
export HTTPS_PROXY=http://username:password@proxy.company.com:8080

セキュリティ上の注意: パスワードを平文で環境変数に保存することはセキュリティリスクが高いため、可能であれば認証トークンやキーリングを使用してください。

ファイアウォール診断チェックリスト

ファイアウォール(FW)は、ネットワークトラフィックをフィルタリングし、不正なアクセスをブロックする仕組みです。 ファイアウォールのルールが厳しすぎると、正当な通信まで遮断されてしまいます。

ファイアウォールの確認コマンド

まず、特定のポートへの接続が可能かを確認します。

bash# telnet コマンドでポート接続を確認
telnet mcp.example.com 443

このコマンドの目的: 指定したホストとポートへの TCP 接続が確立できるかを検証します。

正常な場合の出力例です。

sqlTrying 203.0.113.45...
Connected to mcp.example.com.
Escape character is '^]'.

接続が拒否される場合の出力例です。

vbnetTrying 203.0.113.45...
telnet: connect to address 203.0.113.45: Connection refused
telnet: Unable to connect to remote host

エラーコード: Connection refused エラーメッセージ: Unable to connect to remote host 発生条件: ファイアウォールまたはサーバー側でポートがブロックされている、またはサービスが起動していない

より詳細なポート診断

nc(netcat)コマンドを使用すると、より詳細な診断が可能です。

bash# nc コマンドでポート疎通確認
nc -zv mcp.example.com 443

このコマンドの効果: TCP 接続のみをテストし、実際にデータを送信せずに接続可能性を確認できます。

正常な場合の出力例です。

cssConnection to mcp.example.com 443 port [tcp/https] succeeded!

ファイアウォール設定の診断手順

#確認項目コマンド期待される結果
1ポートの開放状況nc -zv mcp.example.com 443接続成功
2ローカル FW の確認(macOS)sudo ​/​usr​/​libexec​/​ApplicationFirewall​/​socketfilterfw --getglobalstateFW の状態が確認できる
3ローカル FW の確認(Linux)sudo ufw statusFW ルールが確認できる
4トレースルート確認traceroute mcp.example.com経路上のホップが確認できる

ファイアウォール問題の解決方法

  1. macOS ファイアウォールで特定アプリを許可

macOS のファイアウォール設定で、特定のアプリケーションを許可リストに追加できます。

bash# macOS のファイアウォール設定を確認
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate

# 特定アプリを許可リストに追加
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /path/to/app

この設定の効果: 指定したアプリケーションからの外部通信が許可されます。

  1. Linux(ufw)でポートを開放

Ubuntu などの Linux ディストリビューションでは、ufw コマンドでファイアウォールを管理します。

bash# ufw でファイアウォールの状態を確認
sudo ufw status verbose

次に、必要なポートを開放します。

bash# 特定ポートを開放(例: 443)
sudo ufw allow 443/tcp

# 設定を有効化
sudo ufw enable

このコマンドの効果: ポート 443 への TCP 接続が許可され、HTTPS 通信が可能になります。

  1. ネットワーク管理者に開放依頼

企業ネットワークの場合、ネットワーク管理者に以下の情報を提供して、ファイアウォールルールの変更を依頼します。

#提供情報具体例
1送信元 IP/サブネット192.168.10.0/24
2宛先ホスト名mcp.example.com
3宛先 IP アドレス203.0.113.45
4ポート番号443 (HTTPS)
5プロトコルTCP
6用途MCP サーバーへの API 接続

総合診断スクリプト

以下のスクリプトは、DNS・TLS・プロキシ・ファイアウォールの各層を自動で診断します。

bash#!/bin/bash
# MCP サーバー接続診断スクリプト

# 診断対象のホストとポート
HOST="mcp.example.com"
PORT=443

まず、DNS 解決を確認します。

bash# 1. DNS 解決の確認
echo "=== DNS 診断 ==="
nslookup $HOST
if [ $? -eq 0 ]; then
  echo "✓ DNS 解決成功"
else
  echo "✗ DNS 解決失敗"
  exit 1
fi

次に、ポート接続を確認します。

bash# 2. ポート接続の確認
echo ""
echo "=== ポート診断 ==="
nc -zv $HOST $PORT
if [ $? -eq 0 ]; then
  echo "✓ ポート接続成功"
else
  echo "✗ ポート接続失敗(ファイアウォールの可能性)"
  exit 1
fi

TLS ハンドシェイクを確認します。

bash# 3. TLS ハンドシェイクの確認
echo ""
echo "=== TLS 診断 ==="
openssl s_client -connect $HOST:$PORT -servername $HOST < /dev/null
if [ $? -eq 0 ]; then
  echo "✓ TLS ハンドシェイク成功"
else
  echo "✗ TLS ハンドシェイク失敗"
  exit 1
fi

最後に、プロキシ設定を確認します。

bash# 4. プロキシ設定の確認
echo ""
echo "=== プロキシ診断 ==="
if [ -n "$HTTPS_PROXY" ]; then
  echo "プロキシ設定: $HTTPS_PROXY"
  curl -I -x $HTTPS_PROXY https://$HOST
else
  echo "プロキシ設定なし"
fi

echo ""
echo "=== 診断完了 ==="

このスクリプトの使い方: 上記を mcp_diagnose.sh として保存し、実行権限を付与して実行してください。

bash# スクリプトに実行権限を付与
chmod +x mcp_diagnose.sh

# スクリプトを実行
./mcp_diagnose.sh

具体例

ここでは、実際によくある接続失敗のシナリオと、その解決プロセスを具体的に紹介します。

ケース 1: 企業プロキシ環境での接続失敗

状況

会社のネットワーク内から MCP サーバーに接続しようとしたところ、以下のエラーが発生しました。

csharpError: ETIMEDOUT - Connection timed out
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1148:16)

エラーコード: ETIMEDOUT エラーメッセージ: Connection timed out 発生条件: プロキシ経由でないと外部ネットワークにアクセスできない環境で、プロキシ設定が未設定

診断手順

まず、環境変数でプロキシ設定を確認します。

bash# プロキシ設定を確認
echo $HTTPS_PROXY

出力が空の場合、プロキシが設定されていません。

次に、ネットワーク管理者にプロキシ情報を確認し、以下を設定します。

bash# プロキシ情報を設定
export HTTPS_PROXY=http://proxy.company.com:8080
export HTTP_PROXY=http://proxy.company.com:8080
export NO_PROXY=localhost,127.0.0.1,.internal

設定後、再度接続を試みます。

bash# プロキシ経由で接続確認
curl -I https://mcp.example.com

この手順の効果: プロキシ経由で外部ネットワークへのアクセスが可能になります。

解決結果

プロキシ設定を追加した結果、MCP サーバーへの接続が成功しました。

yamlHTTP/2 200
date: Sat, 02 Nov 2025 10:30:45 GMT
content-type: application/json

ケース 2: 自己署名証明書による TLS エラー

状況

開発環境で自己署名証明書を使用している MCP サーバーに接続しようとしたところ、以下のエラーが発生しました。

phpError: unable to verify the first certificate
    at TLSSocket.onConnectSecure (_tls_wrap.js:1501:34)
    at TLSSocket.emit (events.js:314:20)

エラーコード: unable to verify the first certificate 発生条件: サーバーが自己署名証明書を使用しており、クライアント側の信頼ストアに証明書が存在しない

診断手順

OpenSSL で証明書を確認します。

bash# TLS 接続を確認
openssl s_client -connect mcp.example.com:443 -servername mcp.example.com

出力に以下のようなエラーが表示されます。

luaverify error:num=18:self signed certificate
verify return:1
verify error:num=10:certificate has expired
verify return:1

証明書が自己署名であることが確認できました。

解決方法の選択肢

開発環境のため、以下の 2 つの方法から選択します。

方法 1: 証明書検証をスキップ(開発環境のみ)

bash# 環境変数で証明書検証を無効化
export NODE_TLS_REJECT_UNAUTHORIZED=0

方法 2: CA 証明書を信頼ストアに追加

まず、サーバーから CA 証明書を取得します。

bash# サーバーから証明書を取得
openssl s_client -connect mcp.example.com:443 -showcerts < /dev/null \
  | openssl x509 -outform PEM > mcp-ca.crt

次に、証明書を信頼ストアに追加します(macOS の例)。

bash# macOS のシステムキーチェーンに追加
sudo security add-trusted-cert -d -r trustRoot \
  -k /Library/Keychains/System.keychain mcp-ca.crt

この解決策の効果: 自己署名証明書がシステムに信頼され、証明書検証エラーが解消されます。

解決結果

証明書を信頼ストアに追加した結果、TLS ハンドシェイクが成功しました。

yaml---
Verify return code: 0 (ok)
---

ケース 3: ファイアウォールによるポートブロック

状況

新しいサーバー環境で MCP サーバーを起動後、クライアントから接続できない状態が発生しました。

javascriptError: ECONNREFUSED - Connection refused
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1148:16)

エラーコード: ECONNREFUSED エラーメッセージ: Connection refused 発生条件: サーバー側のファイアウォールでポートが閉じられている

診断手順

まず、サーバー側でポートがリスニングしているかを確認します。

bash# サーバー側でリスニング状態を確認
sudo netstat -tlnp | grep 443

正常であれば以下のように表示されます。

bashtcp6  0  0 :::443  :::*  LISTEN  1234/node

次に、クライアント側からポート接続を確認します。

bash# クライアント側からポート疎通確認
nc -zv mcp.example.com 443

接続が拒否される場合、ファイアウォールが原因と判断できます。

vbnetnc: connect to mcp.example.com port 443 (tcp) failed: Connection refused

解決方法

サーバー側のファイアウォールで HTTPS ポート(443)を開放します。

bash# Ubuntu/Debian の場合(ufw)
sudo ufw allow 443/tcp
sudo ufw reload
sudo ufw status

設定後の状態確認です。

vbnetStatus: active

To                         Action      From
--                         ------      ----
443/tcp                    ALLOW       Anywhere
443/tcp (v6)              ALLOW       Anywhere (v6)

この解決策の効果: ファイアウォールルールが更新され、外部からポート 443 への接続が許可されます。

解決結果

ファイアウォールルールを更新した結果、クライアントからの接続が成功しました。

bash# 再度接続確認
nc -zv mcp.example.com 443

出力:

cssConnection to mcp.example.com 443 port [tcp/https] succeeded!

ケース 4: DNS キャッシュ汚染による接続失敗

状況

MCP サーバーの IP アドレスを変更した後、古い IP アドレスへの接続が継続される問題が発生しました。

vbnetError: ETIMEDOUT - Connection timed out to 198.51.100.10

発生条件: DNS キャッシュに古い IP アドレスが残っており、新しい IP アドレスに解決されない

診断手順

現在の DNS 解決結果を確認します。

bash# DNS 解決を確認
nslookup mcp.example.com

出力:

yamlName:    mcp.example.com
Address: 198.51.100.10  # 古い IP アドレス

実際のサーバーは新しい IP アドレス(203.0.113.45)に移行済みです。

解決方法

DNS キャッシュをクリアします。

bash# macOS の場合
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux の場合
sudo systemd-resolve --flush-caches

キャッシュクリア後、再度 DNS 解決を確認します。

bash# 再度 DNS 解決を確認
nslookup mcp.example.com

出力:

yamlName:    mcp.example.com
Address: 203.0.113.45  # 新しい IP アドレス

この解決策の効果: 古い DNS キャッシュがクリアされ、最新の IP アドレスに接続できるようになります。

解決結果

DNS キャッシュをクリアした結果、新しい IP アドレスへの接続が成功しました。

以下の図は、DNS キャッシュによる問題と解決プロセスを示しています。

mermaidsequenceDiagram
  participant Client as クライアント
  participant Cache as DNS キャッシュ
  participant DNS as DNS サーバー
  participant OldIP as 旧サーバー<br/>198.51.100.10
  participant NewIP as 新サーバー<br/>203.0.113.45

  Note over Client,NewIP: キャッシュクリア前
  Client->>Cache: mcp.example.com は?
  Cache-->>Client: 198.51.100.10(古い)
  Client-xOldIP: 接続失敗(タイムアウト)

  Note over Client,NewIP: キャッシュクリア実行
  Client->>Cache: キャッシュクリア

  Note over Client,NewIP: キャッシュクリア後
  Client->>DNS: mcp.example.com は?
  DNS-->>Client: 203.0.113.45(新しい)
  Client->>NewIP: 接続成功
  NewIP-->>Client: レスポンス返却

図で理解できる要点:

  • DNS キャッシュは高速化のため情報を保持し続ける
  • サーバー移行時はキャッシュが古い情報を返してしまう
  • キャッシュクリアにより最新の DNS 情報を取得できる

まとめ

MCP サーバーへの接続失敗やタイムアウトは、DNS・TLS・プロキシ・ファイアウォールといった複数のネットワーク層で発生しうる問題です。 本記事では、各層を体系的に診断するためのチェックリストと具体的な解決方法をご紹介しました。

重要なポイントをまとめます。

  • 診断は DNS → プロキシ → ファイアウォール → TLS の順で行う: 最も基礎的な層から順に確認することで、原因を効率的に絞り込めます
  • 各層ごとに専用の診断コマンドを使用する: nslookup、openssl s_client、nc などのツールを活用しましょう
  • 開発環境と本番環境で対処法を使い分ける: 証明書検証のスキップなど、開発環境でのみ許容される設定を理解しておくことが重要です
  • 総合診断スクリプトを活用する: 定型的な診断プロセスをスクリプト化することで、トラブルシューティングの時間を大幅に短縮できます

これらのチェックリストと診断手順を活用することで、ネットワーク層の接続問題を迅速に解決できるようになるでしょう。 次回接続エラーが発生した際には、ぜひ本記事の診断フローを試してみてください。

関連リンク

MCP サーバーの記事Mcp Server

もっと見る

記事Article

もっと見る

ブログBlog

もっと見る

書籍レビューReview

もっと見る