PowerShell で実行するこれら 4 つのコマンドは、私が遭遇する Windows ネットワークの問題のほとんどを解決します。

先週、インターネットの調子が悪くなり始めました。完全にダウンしたわけではありませんが、Web ページの読み込みが遅く、ビデオ会議では接続の問題が発生し続けました。メッシュ ネットワークとモデムを再起動しましたが、問題は再発し続けました。その時点で、もう少し深く掘り下げる時期が来たことがわかりました。

そこで、これらの PowerShell コマンドが役に立ちます。これらは、問題が PC にあるのか、ネットワークにあるのか、DNS にあるのか、それとも完全に他のものにあるのかを絞り込むのに役立ちます。これらを使用するために PowerShell の専門家である必要はありません。ほとんどの場合、コマンドをコピーして貼り付け、いくつかの重要な情報を確認し、それを使用して次に何を試行するかを判断します。

問題がローカルにあるのかインターネット上にあるのかをテストする

テスト接続は問題の発生箇所を絞り込むのに役立ちます

ここでトラブルシューティングを開始しました。速度低下がネットワーク内で発生しているのか、それともネットワークを超えた場所で発生しているのかを確認したかったからです。 PowerShellの Test-Connection コマンドは基本的に ping と同じ働きをします。テスト パケットを別のデバイスに送信し、パケットが戻ってきたかどうかと、各応答にかかった時間を表示します。

まずはPowerShellを開いて実行しました ipconfig。実際に使用していたネットワークアダプターの下で、 デフォルトゲートウェイ。これはルーターまたはメッシュ ネットワークのアドレスで、ほとんどのホーム ネットワークでは 192.168.1.1 のようになります。次に、次のコマンドを実行しました。

Test-Connection 192.168.1.1 -Count 10

IP を現在のゲートウェイ 192.168.4.1 に置き換えました。そのトラフィックがホーム ネットワークから出ることは決してないので、応答は高速でかなり一貫していると期待されます。特に Wi-Fi 経由では、応答がところどころ若干遅くなることがありますが、それほど問題はありません。私が探しているのは、繰り返されるタイムアウト、応答の欠落、または数ミリ秒から数ミリ秒に突然跳ね上がる応答時間です。

それが正常に見えたら、次のようにネットワークの外側で何かをテストしました。

Test-Connection 8.8.8.8 -Count 10

これにより、同じテストが Google のパブリック DNS サーバーに送信されます。重要な部分は 2 つの結果を比較することです。ゲートウェイが正常に応答しているにもかかわらず、外部テストでタイムアウトまたは大幅な遅延のスパイクが示された場合、問題はおそらく PC とルーターの間にあるのではないことがわかります。両方のテストの結果が悪ければ、自宅に近い PC、Wi-Fi 接続、ルーター、またはメッシュ ネットワークを調べ始めます。ここで私は 1 つの完璧なレイテンシー数値を探しているわけではありません。明らかな不一致、特にパケットの損失、タイムアウト、応答時間の大きな変動を探しています。

Windowsが使用しているDNSサーバーを確認する

Get-DnsClientServerAddress は Windows が使用している DNS サーバーを示します

次に DNS を選択しました。数か月前、別の記事を調べているときに DNS を変更したからです。当時、いくつかの異なる DNS プロバイダーをテストしたため、Windows が誤ってそのうちの 1 つを指定したままになっていないことを確認したかったのです。接続自体はまだ稼働しているにもかかわらず、Web ページの読み込みが遅いため、DNS を除外するのは簡単でした。

PowerShell で、次のコマンドを実行しました。

Get-DnsClientServerAddress

このコマンドは、PC 上の各ネットワーク アダプターに割り当てられた DNS サーバーを表示します。それらを確認するためだけに PowerShell を管理者として実行する必要はありません。実際に使用しているアダプター (私の場合は Wi-Fi) を探して、 サーバーアドレス カラム。ここには、Windows が現在使用している DNS サーバー アドレスが表示されます。

重要なのは、それらの数字が何を意味するのかを知ることです。 Google のパブリック DNS サーバーは、 8.8.8.8 そして 8.8.4.4、一方、Cloudflare は 1.1.1.1 そして 1.0.0.1。ただし、それらのどれも表示されない場合があります。 ISP に DNS を自動的に処理させている場合は、代わりにそのサーバーが表示される可能性があります。特に、以前の記事でテストした DNS サービスの 1 つがまだ構成されているかどうかを確認したいと考えていました。 Get-DnsClientServerAddress 私がまだ Google の DNS を使用していることがわかりました。アドレスを ISP の DNS アドレスに戻しました。これで問題の一部は解決しましたが、ネットワークの問題にはまだ対処しなければなりませんでした。

Windows がどのように接続を構成したかを正確に確認する

Get-NetIPConfiguration を使用すると、全体像を 1 か所で確認できます

DNS を確認した後、Windows が全体として接続をどのように構成したかを確認したいと思いました。 Get-NetIPConfiguration このデータを表示します。このコマンドは、一度に 1 つの設定を確認するのではなく、Windows が使用している IP アドレス、デフォルト ゲートウェイ、DNS サーバーなど、各アダプタの重要なネットワークの詳細を表示します。

走った Get-NetIPConfiguration そして、実際に接続されていたアダプターに焦点を当てました。私の場合はWi-Fiでした。まず最初に確認したのは、 IPv4アドレス Windows に通常のローカル IP アドレスが割り当てられていることを確認します。ほとんどのホーム ネットワークでは、次のようなもので始まります。 192.168 または 10.x。私もチェックしました IPv4デフォルトゲートウェイ Windows がネットワークからのトラフィックの送信先を認識していることを確認し、次に DNS サーバーを調べて、トラブルシューティングを行ったばかりの DNS アドレスを確認しました。

私がここで本当に探しているのは、意味のないものです。デフォルト ゲートウェイがない場合、使用可能な IP アドレスがない場合、または Windows が次のアドレスで始まるアドレスを自分自身に割り当てている場合 169.254、これはルーターから適切なネットワーク構成を取得していないことを示す強力な兆候です。また、このコマンドは、正しいアダプターを探していることを確認するためにも使用します。 Windows ではイーサネット、Wi-Fi、VPN、その他の接続を一覧表示できるため、最初に確認しておかないと、間違った接続のトラブルシューティングに時間がかかってしまいがちです。

問題が発生した場合に Winsock をリセットする

netsh winsock リセットは私が最後に試したものでした

この時点で、私がチェックしたものはすべて正常に見えました。私はすでにモデムとメッシュ ネットワークを再起動し、接続をテストし、DNS をチェックし、Windows がアダプターを構成した方法を調べました。明らかに何も問題はありませんでしたが、接続は依然として正常に動作していませんでした。そこで Winsock をリセットすることにしました。

この手順では、PowerShell を管理者として開き、これを実行しました。

netsh winsock reset

Winsock は、アプリがネットワーク上で通信する方法を処理する Windows の一部であり、Winsock をリセットすると、不適切な構成や何かが行き詰まったために発生した問題を解決できます。コマンドが機能すると、PowerShell は Winsock カタログが正常にリセットされたこと、および完了するにはコンピューターを再起動する必要があることを通知します。

再起動後、以前と同じ方法で、Web ページをロードし、ビデオ会議に参加して、接続をテストしました。ありがたいことに、すべてが再び安定しているように見えました。コマンド出力自体には検査する内容はあまりありません。主に、リセットが正常に完了したことの確認を求めています。本当のテストは再起動後、接続の問題が実際に解消されたかどうかを確認するときに行われます。

PowerShell により問題の追跡が容易になりました

これらのコマンドの優れた点は、実行に時間がかからないことですが、これらのコマンドを組み合わせることで、Windows ネットワークの問題の原因について多くのことがわかることです。私の場合、明らかな決定的な要因は 1 つもありませんでしたが、接続を確認し、DNS を検証し、構成を確認し、最後に Winsock をリセットすることで、推測することなく問題を解決することができました。リセット後に再起動すると、接続は再び安定し、Web ブラウジングとビデオ会議の両方が通常に戻りました。