もくじ
📝 はじめに
「Wi-Fiにはつながっているのにネットが使えない」
「社内サイトだけ開けない」
「VPN接続後に急に通信がおかしい」
こういった相談はとても多いのですが、原因は名前解決(DNS)なのか、接続(疎通)なのかで対処が大きく変わります。
この記事では、PowerShellを使って
ネットワーク疎通不良の原因を「名前解決」と「接続確認」に分けて切り分ける手順を、
できるだけ迷わない順番でまとめます。
「つながらない」「タイムアウトする」「特定のサイトだけ開けない」などの検索語で来た方にも役立つ構成にしています。
- ブラウザで「ページを表示できません」「DNS_PROBE_FINISHED_NXDOMAIN」などが出る
- IP直打ちなら開くが、ドメイン名だと開けない
- 社内LAN・VPN・テザリングなどで接続先を変えると症状が変わる
✅ この手順でできること(要点)
- 「名前解決(DNS)」が原因か、「接続(疎通)」が原因かを切り分けできる
- DNS設定・ルート・ポート開放・ファイアウォールのどこが怪しいか目星を付けられる
- 結果をコピペしやすい形で取得し、相談・報告にも使える
- VPNや複数アダプタ(Wi-Fi/有線/仮想NIC)の混線を整理できる
✅ この切り分け手順でできること
ネットワーク不具合は「ネットがダメ」と一括りにされがちですが、実際には大きく分けて次の2系統があります。
- 名前解決(DNS):ドメイン名(例:example.com)をIPに変換できない
- 接続(疎通):IPは分かっていても、相手に届かない/ポートが開かない
まずここを分けるだけで、無駄な遠回りが減ります。
以降は「最短で原因に近づく順番」で進めます。
🧩 基本構文
# 名前解決(DNS)
Resolve-DnsName example.com
# 疎通確認(ICMP)
Test-Connection example.com
# ポート疎通(TCP)
Test-NetConnection example.com -Port 443
この記事は「最小コマンドで切り分け」する構成です。
途中で迷ったら、先に Get-NetIPConfiguration と Get-DnsClientServerAddress の確認へ戻るのが安全です。
▶ 基本的な使い方(まずこれだけ)
🔎 1) まずは「名前解決できるか」を確認する
Resolve-DnsName example.com
ここでドメイン名がIPに変換されれば、DNSはひとまずOKの可能性が高いです。
逆にエラーになる場合は、まずDNS側(DNSサーバ設定、VPNのDNS上書き、社内DNSの到達性など)を疑います。
- 結果にIP(A/AAAA)が出る → 名前解決できている可能性が高い
- タイムアウト系 → DNSサーバへ到達できていない可能性
- NXDOMAIN → その名前が存在しない、または社内DNSでのみ解決する名前の可能性
🧪 2) 次に「接続(疎通)できるか」を確認する
Test-Connection 1.1.1.1 -Count 2
ドメイン名ではなくIPで試すことで、DNSの影響を避けて「届くかどうか」だけを見られます。
ここが通らない場合は、ルート・ゲートウェイ・Wi-Fi/有線の状態・ファイアウォール・回線側などを疑う流れになります。
🛠 よく使われる指定例
🧭 3) IP設定・ゲートウェイ・DNSをまとめて確認する
Get-NetIPConfiguration
ここで見るべきは「どのアダプタが使われているか」「IPv4アドレス」「デフォルトゲートウェイ」「DNS」です。
VPNや仮想アダプタがある環境では、意図しないアダプタが優先されることがあります。
🧩 4) DNSサーバ設定だけを確認する
Get-DnsClientServerAddress -AddressFamily IPv4
DNSのIPが不自然(例:知らないDNS、空、VPN用に変わっている)なら、ここが起点になることがあります。
🧠 DNSが怪しいときの見方
- DNSが空、または 0.0.0.0 っぽい
- VPN接続時だけDNSが変わる
- 社内ドメインだけ解決できない(社内DNSが必要)
🧠 接続(疎通)が怪しいときの見方
- IP直打ちでも通らない
- ゲートウェイがない/別の回線になっている
- ルート(経路)がVPNに吸われている
💼 実務でよく使う使用例(応用)
🔐 5) HTTPSなど「特定ポート」が通るか確認する
Test-NetConnection example.com -Port 443
Pingは通るのにWebが開かない場合、ICMPとTCPは別物なので、ポート疎通を確認するのが近道です。
ここが失敗する場合は、プロキシ、FW、ルータのフィルタ、サーバ側の停止なども候補になります。
🧭 6) ルート(経路)が想定通りか確認する
Get-NetRoute | Where-Object {$_.DestinationPrefix -eq "0.0.0.0/0"} |
Select-Object DestinationPrefix, NextHop, InterfaceAlias, RouteMetric
デフォルトルート(0.0.0.0/0)がどのアダプタになっているかは重要です。
VPNで全トラフィックが吸われていないか、メトリックで優先順位が逆転していないかを確認できます。
🧱 7) Windowsファイアウォールの影響を確認する
Get-NetFirewallRule | Where-Object {$_.Enabled -eq "True"} | Select-Object -First 10
ルールは大量にあるため、まずは「有効なルールがある」ことを確認し、
次に「対象アプリ・対象ポートのルールがどうなっているか」へ進むのが現実的です。
- Resolve-DnsName → Test-NetConnection -Port 443 で「名前解決→HTTPS接続」を一気に確認
- Get-NetIPConfiguration → Get-NetRoute で「IP設定→経路」の矛盾を探す
- Get-NetTCPConnection で「通信しているアプリ/ポート」を観察して、FWやプロキシの判断材料にする
🧩 よくある勘違い・つまずきポイント
- ping が通らない=ネットが死んでいる、とは限らない(ICMPが遮断されている場合があります)
- DNSが正常でも、ポート(例:443)が塞がれていればWebは開けない場合がある
- VPN接続でDNSやルートが上書きされ、社内向けだけ通る(または逆)ことがある
- 複数アダプタ(Wi-Fi/有線/仮想NIC)でメトリックが逆転し、意図しない回線が優先されることがある
- 「PC側の問題」ではなく、ルータ・回線・サーバ側・セキュリティ製品が原因の場合もある
⚠ エラー・うまく動かないときの確認ポイント
- まず Get-NetAdapter で対象アダプタが Up か確認する
- Resolve-DnsName が失敗するなら、DNS設定(Get-DnsClientServerAddress)と到達性を疑う
- Test-Connection が失敗するなら、ゲートウェイ・ルート(Get-NetRoute)を疑う
- Test-NetConnection -Port が失敗するなら、FW・プロキシ・サーバ側停止・ルータ側フィルタの可能性
- 同じテストを「別回線(テザリング等)」で実施し、PC側か回線側かを切り分ける
🧠 注意点
切り分け中に、DNSやファイアウォールをむやみに変更すると、
かえって原因が分からなくなる場合があります。
まずは確認(取得)→比較→必要最小限の変更の順番で進めるのがおすすめです。
企業環境では、社内DNS・プロキシ・EDR/セキュリティ製品が通信に介入している場合があります。
その場合は「設定を変える」のではなく、まず「現状を採取して報告できる形にする」方が安全です。
📌 まとめ
- 最初に Resolve-DnsName で「名前解決」を切り分ける
- 次に Test-Connection で「到達性(疎通)」を見る
- Web系は Test-NetConnection -Port でポート疎通まで確認する
- 設定確認は Get-NetIPConfiguration と Get-NetRoute が軸
- FW影響が疑わしいなら Get-NetFirewallRule で絞り込む
🔎 PowerShellコマンドを探す
「やりたいこと」から関連コマンドを探せます。たとえば次のように検索すると見つけやすいです。
- ファイルを削除したい
- 一覧を表示したい
- 文字列を検索したい
- 条件で絞り込みたい
- エラーや実行できない原因を調べたい
- DNSを確認したい(Get-DnsClientServerAddress)
- 名前解決をテストしたい(Resolve-DnsName)
- ポート疎通を確認したい(Test-NetConnection)
- ルート(経路)を確認したい(Get-NetRoute)
下の検索フォームで、目的のコマンドを探せます。
例:DNS 変更 / 名前解決 / ポート 443 / ルート確認 / ファイアウォール 受信 / プロキシ
