「pingは通る。なのにWebサイトが開かない」。逆に、「pingはタイムアウトするのに、ブラウザでは普通に開ける」。どちらも矛盾ではありません。

pingが確かめるのはICMPの応答で、Webやリモートデスクトップが使うTCPポートへの接続とは別です。 同じサーバーでも、通す通信と止める通信を分けられます。pingの成功だけで「ネットワークは正常」と決めたり、失敗だけで「サーバーが停止した」と決めたりすると、調べる場所を間違えます。

この記事では、Windowsの Test-NetConnection を使い、どのPCから、どの宛先へ、どのTCPポートで接続した結果なのかをそろえて切り分けます。無料動画の疎通確認とAzure Network Watcherの障害実演を素材に、コマンドの仕様は2026年10月14日時点のMicrosoft Learnで確認しました。

pingの結果を、アプリの接続結果に置き換えない

たとえば、社内WebサーバーのHTTPSは通常TCP 443番を使います。pingに返事があっても、443番の通信が途中で止められていたり、サーバーでそのポートを待ち受けていなかったりすればWebサイトにはつながりません。

反対に、ICMPへの応答を止め、HTTPSだけ許可している構成なら、pingは失敗してもWebサイトは開けます。

そこで、問題が起きているPCでWindows PowerShellを開き、実際に使う宛先とポートを指定します。次は書き方の例です。web.example.com は、自分が利用するサーバーの名前に置き換えてください。

Test-NetConnection -ComputerName web.example.com -Port 443 -InformationLevel Detailed

まず見るのは TcpTestSucceeded。True は指定したTCPポートへの接続に成功したという意味です。PingSucceeded と取り違えないでください。-Port を省いた疎通確認と、ポートを指定したTCPテストは、確認しているものが違います。

公式リファレンス「Test-NetConnection」には、TCPテストと詳細出力の例が載っています。無料動画の45秒からはコマンドを使った疎通確認、1分4秒からは宛先IP・送信元IP・インターフェイスを読む場面です。動画は主にポート指定なしの確認なので、TCPテストの書き方は上のリファレンスと合わせて使ってください。

Trueでも、ログインできるとは限らない

TcpTestSucceeded : True が保証する範囲は、TCP接続までです。HTTPSの証明書が正しいか、Webアプリが正常な応答を返すか、ユーザーの認証に成功するかまでは確かめません。

結果・症状 次に確かめるもの
pingは成功、TCPテストは失敗 指定したポートの待ち受け、途中と宛先の通信制御、経路
pingは失敗、TCPテストは成功 必要なTCP接続は成立。ping失敗だけで故障と決めない
TCPテストは成功、ブラウザには証明書の警告 接続先の名前、証明書の信頼、有効期限など
TCPテストは成功、アクセス拒否やログイン画面が出る アプリの認証・アクセス許可、実際のHTTP応答

この表は診断の目安です。False だけで「ファイアウォールが原因」と断定はできません。サービスが動いていない場合も、宛先やポートを間違えた場合も失敗します。

証明書の警告に進んだ場合は、TCPポートの確認から証明書が何を保証するのかへ調べる対象を移します。共有フォルダーなら通常TCP 445番を確認しますが、接続できても認証や権限で止まることがあります。共有フォルダーにアクセスできないときの6段階の切り分けで、その先を追えます。

なお Test-NetConnection -Port はTCPのテストです。UDPで動く通信を、同じポート番号を指定しただけで検証したことにはなりません。

「どこから試したか」まで記録する

「サーバーではつながった」という報告と「手元ではつながらない」という報告は、両方正しいことがあります。送信元が違えば、使う経路や適用される通信ルールも変わるからです。

詳細出力では次を読みます。

  • RemoteAddress：実際に接続を試した宛先IP。名前が同じでも、期待したIPかを確かめる。
  • SourceAddress：その通信に使われた送信元IP。
  • InterfaceAlias：どのネットワークインターフェイスを使ったか。VPNや複数の接続があるときに手がかりになる。
  • RemotePort と TcpTestSucceeded：何番へのTCP接続が成功・失敗したか。

無料動画の1分26秒からは、複数インターフェイスがある環境で、この情報が役立つ理由を説明しています。

担当者へ渡すなら「つながらない」だけではなく、問題が起きたPC、実行日時、宛先名、出力にある宛先IP・送信元IP・ポート・結果をセットにします。別のPCで成功した結果は比較材料であり、問題が起きているPCでの確認の代わりにはなりません。

Azureでは、失敗した接続から拒否ルールをたどる

Azure VM同士でTCP接続が失敗した場合も、いきなりすべての通信を許可する必要はありません。Azure Network Watcherの「接続のトラブルシューティング」は、送信元と宛先を指定し、NSG（ネットワークセキュリティグループ）や経路などの問題を調べる機能です。対象と検出できる問題は、公式の「Connection troubleshoot overview」で確認できます。

無料のNetwork Watcher動画では、6分18秒から、クライアントVMからWebサーバーVMへの接続を監視する、という対象を決めます。17分33秒からの診断結果では、送信側のNSGは許可、受信側のNSGは拒否になっており、18分2秒からは拒否したルールの詳細を追います。

失敗した通信を特定してから、それを止めている設定を読む。 これが、手当たり次第に設定を変える方法との違いです。動画は意図的に入れた拒否ルールを許可へ変えるデモです。実環境では、その拒否が意図した制御かを管理者と確認し、必要な送信元・宛先・ポートの範囲で変更します。

接続先のIPが、本当にそのVMへ結び付いているか

Azureの公開IPを使う構成では、IPリソースを作っただけで、そのVMの接続先になったと思い込まないことも大切です。

メンバー限定の「Bicep入門 #12」では、42秒から、NICのIP構成に公開IPが関連付いていない状態を確認します。7分19秒からは、ポータルで構成した結果のJSONを見て、コード側の参照へ戻す場面です。別々のリソースがどこでつながるのかは、文字だけで読むより、この画面の往復で追うと分かりやすくなります。参加していない場合は、リンク先でメンバーシップの案内が表示されます。

これは公開IPを使う構成の補助教材で、pingやTCPの障害診断そのものを扱う動画ではありません。2022年のデモのため、当時のAPIバージョンやツールの挙動をそのまま再現する手順としては使わず、NICのIP構成とリソース参照の関係に注目してください。公開IPの追加は、接続失敗に対する万能の対処ではありません。

コード化する方法を詳しく追いたい場合は、ポータルで作った結果からBicepを書く考え方も参考になります。

直したあとも、同じ接続で確かめる

設定を直したら、最初に失敗したPCから、同じ宛先とポートでTCPテストをやり直します。そのうえでブラウザや業務アプリでも確認します。TCP接続だけが戻り、認証やアプリ側の問題が残ることもあるからです。

継続監視なら、Azureの接続モニターで送信元・宛先・プロトコル・テスト頻度・しきい値を決めます。公式「Connection Monitor overview」に、テスト構成と結果の見方がまとまっています。無料動画の19分33秒からは、ルール修正後に失敗率のグラフが下がる場面です。状態表示はテスト間隔や集計範囲の影響を受けるため、変更直後の表示1つで直っていないと判断しないでください。

pingは便利な最初の確認です。ただし、仕事で困っているのは「pingが返るか」ではなく「必要な接続が使えるか」。宛先、TCPポート、送信元をそろえて調べ、TCP接続が戻ったらアプリの確認まで進む。この順番を守ると、次に見るべき場所が絞れます。