ポートの枯渇問題のトラブルシューティング

TCP プロトコルと UDP プロトコルは、接続の確立に使用されるポート番号に基づいて機能します。 TCP/UDP 接続を確立する必要があるアプリケーションまたはサービスには、その側にポートが必要です。

ポートには次の 2 種類があります。

  • Ephemeral ポート(通常は動的ポート) は、すべてのコンピューターが既定で送信接続を行うポートのセットです。
  • 既知のポートは、 特定のアプリケーションまたはサービスの定義されたポートです。 たとえば、ファイル サーバー サービスはポート 445、HTTPS は 443、HTTP は 80、RPC は 135 です。 カスタム アプリケーションには、定義されたポート番号も設定されます。

アプリケーションまたはサービスに接続する場合、クライアントはコンピューターから一時的なポートを使用して、そのアプリケーションまたはサービス用に定義された既知のポートに接続します。 クライアント コンピューター上のブラウザーは、一時的なポートを使用してポート https://www.microsoft.com 443 に接続します。

同じブラウザーが複数の Web サイトへの多数の接続を作成しているシナリオでは、ブラウザーが試行している新しい接続に対して、一時的なポートが使用されます。 しばらくすると、接続が失敗し始める可能性が高いのは、ブラウザーが使用可能なすべてのポートを使用して外部に接続し、新しく接続を確立しようとした場合、使用可能なポートがもうないので失敗する可能性があります。 すべてのポートがコンピューター上に使用されている場合は、ポートの枯渇 と言います

TCP/IP の既定の動的ポート範囲

インターネット割り当て番号機関 (IANA) の推奨事項に準拠するために、Microsoft は送信接続の動的クライアント ポート範囲を拡大しました。 新しい既定の開始ポートは 49152で、新しい既定のエンド ポートは 65535 です。 これは 、1025 ~ 5000の既定のポート範囲を使用Windows以前のバージョンの構成からの変更です

次の netsh コマンドを使用して、コンピューター上の動的ポート範囲を表示できます。

  • netsh int ipv4 show dynamicport tcp
  • netsh int ipv4 show dynamicport udp
  • netsh int ipv6 show dynamicport tcp
  • netsh int ipv6 show dynamicport udp

範囲は、トランスポート (TCP または UDP) ごとに個別に設定されます。 ポート範囲は、開始点と終了点を持つ範囲になります。 サーバーを実行しているサーバーを展開する microsoft Windows内部ネットワークでファイアウォールが使用されている場合、サーバー間の RPC 通信に影響する問題が発生する可能性があります。 このような状況では、ファイアウォールを再構成して 、49152 ~ 65535の動的ポート範囲のサーバー間のトラフィックを許可することをお勧めします。 この範囲は、サービスおよびアプリケーションで使用される既知のポートに加えてです。 または、サーバーで使用されるポート範囲を各サーバーで変更できます。 この範囲は、次のように netsh コマンドを使用して調整します。 上記のコマンドは、TCP の動的ポート範囲を設定します。

netsh int <ipv4|ipv6> set dynamic <tcp|udp> start=number num=range

開始ポートは数値で、ポートの総数は範囲です。 コマンドの例を次に示します。

  • netsh int ipv4 set dynamicport tcp start=10000 num=1000
  • netsh int ipv4 set dynamicport udp start=10000 num=1000
  • netsh int ipv6 set dynamicport tcp start=10000 num=1000
  • netsh int ipv6 set dynamicport udp start=10000 num=1000

次のサンプル コマンドでは、動的ポート範囲をポート 10000 から開始し、ポート 10999 (1000 ポート) で終了します。 設定できるポートの最小範囲は 255 です。 設定できる最小開始ポートは 1025 です。 (構成されている範囲に基づく) 最大エンド ポートは 65535 を超えすることはできません。 Windows Server 2003 の既定の動作を複製するには、開始ポートとして 1025 を使用し、TCP と UDP の両方の範囲として 3976 を使用します。 これにより、開始ポートは 1025、終了ポートは 5000 になります。

具体的には、着信接続としての送信接続については、接続を受け入れるエフェメラル ポートは必要としません。

送信接続が失敗し始めるので、次の動作の多くが表示されます。

  • ドメイン資格情報を使用してコンピューターにサインインできませんが、ローカル アカウントでのサインインは機能します。 ドメイン サインインでは、再び送信接続である認証のために DC に連絡する必要があります。 キャッシュ資格情報が設定されている場合、ドメイン サインインは引き続き機能する可能性があります。

    イベント ビューアーでの NETLOGON のエラーのスクリーンショット。

  • グループ ポリシーの更新の失敗:

    グループ ポリシーエラーのイベント プロパティのスクリーンショット。

  • ファイル共有にアクセスできません。

    エラー メッセージ "Windowsアクセスできません" のスクリーンショット。

  • 影響を受けるサーバーからの RDP が失敗します。

    リモート デスクトップが接続できない場合のエラーのスクリーンショット。

  • コンピューター上で実行されている他のアプリケーションは、エラーの発生を開始します。

サーバーを再起動すると問題は一時的に解決されますが、一時的に戻ってくるすべての現象が表示されます。

コンピューターがポートの枯渇状態にあると思われる場合は、次の条件を実行します。

  1. 送信接続を作成してみてください。 サーバー/コンピューターからリモート共有にアクセスするか、RDP を別のサーバーに試したり、ポート上のサーバーに Telnet 接続したりします。 これらすべての送信接続が失敗した場合は、次の手順に進みます。

  2. イベント ビューアーを開き、システム ログの下で、現在の状態を明確に示すイベントを探します。

    a. イベント ID 4227

    イベント ビューアーのイベント ID 4227 のスクリーンショット。

    b. イベント ID 4231

    イベント ビューアーのイベント ID 4231 のスクリーンショット。

  3. サーバーからの netstat -anob 出力を収集します。 netstat の出力には、1 つの PID のTIME_WAITのエントリ数が表示されます。

    netstate コマンド出力のスクリーンショット。

セッションが正常に閉じ込めまたは突然終了した後、4 分 (既定) の期間が終了すると、プロセスまたはアプリケーションを使用したポートが使用可能なプールに解放されます。 この 4 分間、TCP 接続状態はTIME_WAITされます。 ポートの枯渇が疑われる状況では、アプリケーションまたはプロセスは、使用したポートをすべて解放する機能を持ち、TIME_WAIT状態にTIME_WAITされません。

同じ出力に CLOSE_WAIT 状態接続が表示される場合がありますが、CLOSE_WAIT 状態は、TCP ピアの一方の側に送信するデータ (FIN 送信) がないが、もう一方の端からデータを受信できる状態です。 この状態は、必ずしもポートの枯渇を示すとは限りません。

注意

最初の 2 TIME_WAITが確認されない限り、サーバーが現在ポートから外れ、巨大な接続が存在する場合は常に示されません。 多くの接続TIME_WAITは、プロセスが多くの TCP 接続を作成し、最終的にポートの枯渇につながる可能性を示します。

Netstat は 、-Q Windows 10を追加して、BOUND 状態と同様に時間外待機状態に移行したポートを表示するために更新されました。 この機能をWindows 8.1 R2 Windows Server 2012更新プログラムがリリースされました。 このコマンドの PowerShell Get-NetTCPConnection コマンドレットWindows 10これらの BOUND ポートも表示されます。

2016 年 10 月 10 日まで、netstat は不正確でした。 2012 R2 にバックポートされた netstat の修正プログラムで、Netstat.exe および Get-NetTcpConnection が R2 で TCP または UDP ポートの使用状況を正しく報告Windows Server 2012しました。 詳細についてはWindows Server 2012 R2: Ephemeral ポートの修正プログラムを参照してください。

  1. 管理モードでコマンド プロンプトを開き、次のコマンドを実行します。

    Netsh trace start scenario=netconnection capture=yes tracefile=c:\Server.etl
    
  2. ネットワーク モニターを使用して server.etl ファイルを開き、[フィルター] セクションで、フィルター Wscore_MicrosoftWindowsWinsockAFD.AFD_EVENT_BIND を適用します。Status.LENTStatus.Code == 0x209. 次に示すエントリが表示STATUS_TOO_MANY_ADDRESSES。 エントリが見つからない場合でも、サーバーはポートから外れ続けではありません。 見つけた場合は、サーバーがポートの枯渇の下にあるか確認できます。

ポートの枯渇のトラブルシューティング

キーは、すべてのポートを使用しているプロセスまたはアプリケーションを識別します。 1 つのプロセスに分離するために使用できるツールの一部を以下に示します。

方法 1

まず、netstat 出力を確認します。 このコマンドをWindows 10またはWindows Server 2016、コマンドを実行して、最大エントリが BOUND であるプロセス netstat -anobq ID を確認できます。 または、次の Powershell コマンドを実行してプロセスを識別することもできます。

Get-NetTCPConnection | Group-Object -Property State, OwningProcess | Select -Property Count, Name, @{Name="ProcessName";Expression={(Get-Process -PID ($_.Name.Split(',')[-1].Trim(' '))).Name}}, Group | Sort Count -Descending 

ほとんどのポート リークは、エラーが発生した場合にユーザー モード プロセスがポートを正しく閉じない場合に発生します。 ユーザー モード レベルのポート (実際にはソケット) はハンドルです。 TaskManager と ProcessExplorerの両方でハンドル数を表示できます。これにより、すべてのポートを使用しているプロセスを特定できます。

サーバー 7 Windowsおよびサーバー 2008 R2 Windows、Powershell のバージョンを更新して、上記のコマンドレットを含めできます。

方法 2

方法 1 でプロセスを識別できない場合 (R2 のWindows 10およびWindows Server 2012)、タスク マネージャーを確認してください。

  1. 詳細/プロセスの下に "handles" という列を追加します。

  2. 列ハンドルを並べ替え、ハンドルの数が最も多いプロセスを識別します。 通常、3000 を超えるハンドルを持つプロセスは、System、lsass.exe、store.exe、sqlsvr.exe のようなプロセスを除いて、原因sqlsvr.exe。

    タスク の [ハンドル] 列Windowsスクリーンショットです。

  3. これら以外のプロセスの数が多い場合は、そのプロセスを停止し、ドメイン資格情報を使用してログインし、成功した場合に確認してください。

方法 3

タスク マネージャーがプロセスを特定するのに役立たなかった場合は、プロセス エクスプローラーを使用して問題を調査します。

プロセス エクスプローラーを使用する手順:

  1. プロセス エクスプローラーをダウンロードし 、管理者特権 で実行します

  2. Alt キーを押しながら列ヘッダーをクリックし、[列の選択] を選択し、[プロセスのパフォーマンス] タブ [ハンドル数] を追加します

  3. [表示 ] \ [下部ウィンドウの表示] を選択します

  4. [表示 ] \ [下ウィンドウ ビュー] \ [ハンドル] を選択します

  5. [ハンドル] 列を クリックして、その値で並べ替えを行います。

  6. 他のプロセスよりもハンドル数が多いプロセスを調べてください (送信接続ができない場合は、10,000 を超える可能性があります)。

  7. クリックすると、ハンドル数が多いプロセスの 1 つを強調表示します。

  8. 下のウィンドウでは、次に示すハンドルはソケットです。 (ソケットは技術的にはファイル ハンドルです)。

    ファイル \Device\AFD

    プロセス エクスプローラーのスクリーンショット。

  9. 一部は正常ですが、多数は (数百から数千) ではありません。 問題のプロセスを閉じます。 送信接続が復元された場合は、アプリが原因であることがさらに証明されています。 そのアプリのベンダーに問い合わせ。

最後に、上記の方法でプロセスを分離するのに役立たなかった場合は、問題の状態でコンピューターの完全なメモリ ダンプを収集してください。 ダンプは、最大ハンドルを持つプロセスを示します。

回避策として、コンピューターを再起動すると、コンピューターは正常な状態に戻り、当分の間問題を解決するのに役立ちます。 ただし、再起動が非現実的な場合は、次のコマンドを使用してコンピューター上のポートの数を増やして検討することもできます。

netsh int ipv4 set dynamicport tcp start=10000 num=1000

これにより、動的ポート範囲がポート 10000 から開始され、ポート 10999 (1000 ポート) で終了します。 設定できるポートの最小範囲は 255 です。 設定できる最小開始ポートは 1025 です。 (構成されている範囲に基づく) 最大エンド ポートは 65535 を超えすることはできません。

注意

動的ポート範囲を増やすのは永続的なソリューションではなく、一時的なソリューションに限定される点に注意してください。 最大ポート数を消費しているプロセス/プロセッサを追跡し、そのプロセスの観点から、ポートの数が多い理由をトラブルシューティングする必要があります。

サーバー 7 Windowsおよびサーバー 2008 R2 Windows、以下のスクリプトを使用して、定義された頻度で netstat 出力を収集できます。 出力から、ポートの使用状況の傾向を確認できます。

@ECHO ON
set v=%1
:loop
set /a v+=1
ECHO %date% %time% >> netstat.txt
netstat -ano >> netstat.txt
 
PING 1.1.1.1 -n 1 -w 60000 >NUL
 
goto loop
  • ポートの枯渇とあなた! - この記事では、netstat 状態の詳細と、netstat 出力を使用してポートの状態を判断する方法について説明します。

  • 一時的なポートの枯渇を検出する : この記事には、ポートの状態を報告するループで実行されるスクリプトがあります。 (2012 Windows R2、Windows 8、Windows 10、Windows 11)