PCがネットワークにつながらない？原因は端末側が多い｜まず確認する5つのチェックリスト

「PCがネットワークにつながらない」という問い合わせは、ネットワークエンジニアにとって日常茶飯事です。しかし原因の幅が広く、スイッチ・ルータ・サーバなどネットワーク側を疑い始めると調査に時間がかかってしまいます。

実際の問い合わせ対応では、原因は端末（PC）側にあることがほとんどです。この記事では、問い合わせ対応でよく当たる「端末側の原因」を5つに整理し、切り分け手順までまとめます。

切り分けの基本方針：確認する順番

「つながらない」は原因の幅が広いので、順番を決めることが最も重要です。以下の順で確認すれば、無駄にルータやスイッチを疑う時間が減ります。

原因1：PCのIPアドレスが違う（固定IPなのにDHCPなど）

適当なIPが設定されていたり、環境に合わない設定（例：固定IPが必要なのにDHCP）が入っていると、ネットワークに参加できず通信できません。特にPC移設時・OS再セットアップ後に多く発生します。

確認コマンド

REM Windows
ipconfig /all

# Linux
ip addr show
# または
ifconfig

（Windows ipconfig /all の出力例：正常）
Ethernet adapter イーサネット:
   IPv4 Address. . . . . . . . . . . : 192.168.1.50  ← セグメントが正しいか
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.1.1
   DNS Servers . . . . . . . . . . . : 192.168.1.10

（問題のある例：DHCP未設定環境でAPIPAアドレス取得）
   IPv4 Address. . . . . . . . . . . : 169.254.x.x  ← DHCPが取れていない証拠

原因2：GW（デフォルトゲートウェイ）が違う・未設定

IPアドレスが正しくても、GWが未設定または誤っていると、同一セグメント外への通信ができません。同じフロアのPCどうしは通信できるのにインターネットや他セグメントに出られない場合はここを疑います。

確認コマンド

REM Windows：ルーティングテーブルの確認
route print

REM GWへのpingで到達確認
ping 192.168.1.1

# Linux：ルーティングテーブルの確認
ip route show
# または
route -n

（route print の出力例）
IPv4 ルート テーブル
アクティブ ルート:
ネットワーク先      ネットマスク        ゲートウェイ
0.0.0.0           0.0.0.0           192.168.1.1     ← デフォルトゲートウェイ
192.168.1.0       255.255.255.0     On-link         ← ローカルセグメント

（問題のある例：デフォルトルートがない）
0.0.0.0 の行が存在しない → GW未設定の状態

ありがちな落とし穴：無線と有線の同時接続

特に見落とされやすいのが、無線APと有線を両方つないだ状態です。無線側のGWが優先されてしまい、専用有線の通信ができない（社内NWに入れない）ことがあります。

原因3：ファイアウォールで通信が拒否されている（新設PC・サーバで多い）

新しく設置したPCやサーバに接続できない場合、相手側（新設機器側）のファイアウォールで拒否されているケースがよくあります。pingは通るのに特定のアプリやポートだけ通らない場合がこれに当たります。

症状と切り分け方法

REM Windows：ポートの疎通確認
telnet [IPアドレス] [ポート番号]
Test-NetConnection -ComputerName [IP] -Port [ポート番号]

REM 例：RDP(3389)の確認
Test-NetConnection -ComputerName 192.168.1.100 -Port 3389

# Linux：ポート疎通確認
nc -zv 192.168.1.100 3389
# または
telnet 192.168.1.100 3389

原因4：DNSが設定されていない（名前解決ができない）

「Webが開けない」「サーバ名でアクセスできない」場合はDNSを疑います。DNSがないと、URLやホスト名がIPアドレスに変換できず通信できません。「IP直打ちはつながるのに名前だとつながらない」はDNSが原因の典型症状です。

確認コマンドと切り分け手順

REM Windows：DNS設定の確認
ipconfig /all

REM 名前解決のテスト
nslookup google.com
nslookup 社内サーバ名

REM DNSキャッシュのクリア（設定変更後は実行推奨）
ipconfig /flushdns

# Linux：名前解決のテスト
nslookup google.com
dig google.com
host google.com

（nslookup の正常な出力例）
> nslookup google.com
Server:  192.168.1.10         ← 社内DNSサーバ
Address: 192.168.1.10#53

Non-authoritative answer:
Name:    google.com
Address: 142.250.x.x          ← 名前解決成功

（問題のある出力例）
> nslookup google.com
** server can't find google.com: NXDOMAIN   ← DNS解決失敗

原因5：物理的要因（LANケーブル・断線・ポート不良）

意外と多いのが物理です。設定を疑う前に、まずここを30秒で潰すのが効率的です。「設定はすべて正しいのに通信できない」ときに最後に気づくと半日以上が無駄になります。

REM Windows：NICの状態確認
ipconfig /all   （"Media disconnected" が出たらリンクが取れていない）

# Linux：リンク状態の確認
ip link show eth0
# 出力に "state DOWN" があればリンクダウン
# "state UP" なら物理的には接続されている

すぐ使えるチェックリスト（現場用）

よくある質問（FAQ）