レスキューナウエンジニアの坂本です。
今回は実務で原因追及に大変時間を要したConnection Reset by Peer問題についてたまたまproxy経由のリクエストを行っていた際にログが取得できたので再度まとめて記載します。
インターネットを利用する際、特にHTTPSを介した通信では、安定した接続が不可欠です。しかし、時折「Connection Reset by Peer（接続がピアによってリセットされました）」というエラーメッセージに遭遇することがあります。このエラーは、通信の途中で接続が予期せず終了したことを示しています。本記事では、HTTPSリクエストにおいて「Connection Reset by Peer」が発生する主な条件や原因について詳しく解説します。
「Connection Reset by Peer」とは？
「Connection Reset by Peer」とは、通信相手（ピア）がTCP接続をリセット（RSTパケットを送信）したことを示すエラーメッセージです。これは主にTCP/IP通信において発生し、クライアントとサーバー間でデータの送受信中に、相手側が接続を突然切断した場合に表示されます。多くの場合、クライアントがこのエラーを受け取ると、それはサーバー側が接続をリセットしたことを意味します。
HTTPSリクエストにおける発生条件
HTTPSはHTTPにTLS（Transport Layer Security）による暗号化を施したプロトコルです。そのため、HTTPSリクエストにおける「Connection Reset by Peer」は、通常のHTTP通信に比べて複雑な要因が絡むことがあります。以下に、主な発生条件を挙げます。
1. サーバー側の問題
過負荷やリソース不足: サーバーが過負荷状態にある場合、リクエストを処理しきれずに接続をリセットすることがあります。また、メモリやCPUリソースが不足している場合も同様です。
サーバーの設定ミス: TLSの設定ミスや、接続タイムアウトの設定が厳しすぎる場合、正常な通信が行えずに接続がリセットされることがあります。
アプリケーションエラー: サーバー側のアプリケーションにバグが存在する場合、予期せず接続を終了することがあります。
2. ネットワークの問題
不安定なネットワーク接続: ネットワークの遅延やパケットロスが多発すると、TCP接続が正常に維持できず、リセットされる可能性があります。
ファイアウォールやプロキシの干渉: 中間に配置されたファイアウォールやプロキシサーバーが、セキュリティポリシーに基づき接続を遮断またはリセットすることがあります。
3. プロキシサーバーの影響
プロキシサーバーの設定不良: プロキシサーバーを経由すると「Connection Reset by Peer」が頻発することがあります。これはプロキシサーバーの設定やキャッシュ機構に問題がある場合に発生します。
SSL/TLSの中継失敗: 一部のプロキシサーバーは、SSL/TLS通信を適切に中継できないことがあります。この場合、ハンドシェイクが失敗し、接続がリセットされる可能性があります。
セキュリティポリシーの制限: プロキシサーバーが組織内のセキュリティポリシーに基づき、特定のHTTPS通信をブロックまたはリセットすることがあります。
4. SSL/TLSハンドシェイクの失敗
証明書の問題: サーバーのTLS証明書が無効、期限切れ、または信頼されていない場合、クライアントは接続を確立できず、エラーが発生します。一部のサーバーやセキュリティ装置は、この際に接続をリセットすることがあります。
プロトコルや暗号スイートの不一致: クライアントとサーバー間でサポートされるTLSのバージョンや暗号スイートが一致しない場合、ハンドシェイクが失敗し、接続がリセットされることがあります。
5. クライアント側の問題
ソフトウェアのバグ: クライアント側のアプリケーションにバグが存在する場合、接続を正常に維持できずにリセットされることがあります。
過剰なリクエスト: クライアントが短時間に大量のリクエストを送信すると、サーバーが攻撃とみなして接続をリセットすることがあります。
6. セキュリティソフトウェアの干渉
ウイルス対策ソフトや侵入検知システム（IDS/IPS）: これらのセキュリティソフトウェアが、疑わしい通信と判断した場合、接続をリセットすることがあります。
ファイアウォールの設定: ファイアウォールが特定のポートやプロトコルをブロックしている場合、接続がリセットされることがあります。
「Connection Reset by Peer」を防ぐための対策
1. サーバーの監視とリソース管理
リソースの最適化: サーバーのCPU、メモリ、ネットワーク帯域を常に監視し、過負荷を防ぐための適切なリソース管理を行います。
スケーラビリティの確保: トラフィック増加に対応できるよう、サーバーのスケーラビリティを確保します。
2. TLS設定の最適化
最新のTLSプロトコルの使用: TLS 1.3などの最新プロトコルを使用し、セキュアな通信を確保します。
安全な暗号スイートの選択: 古い暗号スイートを無効化し、強力な暗号化方式を採用します。
証明書の管理: サーバー証明書の有効期限を定期的に確認し、期限切れを防ぎます。
3. ネットワークとプロキシサーバーの安定化
ネットワーク機器の品質向上: 高品質なネットワーク機器を使用し、遅延やパケットロスを最小限に抑えます。
プロキシサーバーの設定見直し: プロキシサーバーの設定を確認し、SSL/TLS通信が適切に中継されるようにします。
キャッシュのクリア: プロキシサーバーのキャッシュが原因で問題が発生している場合、キャッシュのクリアや設定の調整を行います。
4. ファイアウォールやセキュリティソフトの設定見直し
正当な通信の許可: ファイアウォールやセキュリティソフトの設定を調整し、正当な通信が遮断されないようにします。
ログの確認: セキュリティソフトウェアのログを確認し、問題の原因を特定します。
5. アプリケーションのテストとデバッグ
バグ修正: クライアントおよびサーバー側のアプリケーションを十分にテストし、バグを修正します。
更新の適用: ソフトウェアの最新バージョンを使用し、既知の問題を回避します。
6. 適切なタイムアウト設定
タイムアウトの最適化: 接続のタイムアウトを適切に設定し、必要以上に早く接続が切断されないようにします。
再試行の設定: 接続失敗時の再試行回数や間隔を調整し、安定した接続を維持します。
実際に試してみる
基本的には上記のRSTパケットを受信した場合に発生します。要因は様々ですがフリーで公開されているプロキシサーバーを総当たりした場合に幾つか発生したので実行結果と要因を見てみます。デフォルトでは理由は返却してもらえませんがプロキシによっては出力してくれるものもありました。
以下のサイトにproxyがまとまっています。
proxy_listから全てのproxyサーバーにリクエストを送信するシェル
# プロキシリストからproxyのURLを取得して変数に格納
proxy_list=$(jq -r '.proxies[].proxy' proxy_list_dir/proxy_list1.json)
# proxy_listを配列に変換
proxy_list=($proxy_list)
for proxy in ${proxy_list[@]}; do
echo $proxy
# proxyのprotocolがhttpではない場合はリクエストをスキップ
if [[ $proxy == http* ]]; then
echo "http"
else
continue
fi
# リクエストを送信 タイムアウトは200秒
curl -k -x $proxy -X POST "google.com" \
-H "Content-Type: application/json" \
--max-time 200 >> log3.txt 2>&1
if [ $? -eq 0 ]; then
echo "\n成功"
else
echo "\n失敗"
fi
done
実行結果
$ curl -k -x http://103.69.20.42:58080 -X POST "google.com" \
-H "Content-Type: application/json" \
--max-time 200
curl: (56) Recv failure: Connection reset by peer
上記の例は一般的なものになります。何が起きたかはユーザー視点ではわかりませんがプロキシサーバーからRSTバケットを受け取っています。
$ curl -k -x http://104.244.78.150:5555 -X POST "google.com" \
-H "Content-Type: application/json" \
--max-time 200
curl: (56) Recv failure: Connection reset by peer
Maximum number of open connections reached.
これはプロキシサーバーの接続数が上限に達した場合に発生しています。
今回の実験では2ケースほどしか確認できませんでしたが、実際には前記の通り様々な要因があります。
まとめ
「Connection Reset by Peer」は、HTTPS通信において様々な要因で発生する可能性があります。サーバーやネットワークの設定、プロキシサーバーの問題、TLSの設定、セキュリティソフトの干渉など、原因は多岐にわたります。これらの問題を未然に防ぐためには、適切な監視と設定、定期的なメンテナンスが不可欠です。
特にプロキシサーバーを経由する環境では、プロキシの設定や動作が通信の安定性に大きく影響します。
Discussion