この記事では、AWSエンジニアが実務のトラブルシュートで実際に使うネットワーク確認コマンドを、出力例・読み方・AWSでの活用場面とあわせて解説します。
対象はAWS初心者エンジニア(実務経験あり)で、ネットワーク知識編と合わせて読むとより効果的です。
記事を読み終えると、「繋がらない」を体系的に切り分けるコマンド活用フローと、現場ですぐ使えるチートシートが手に入ります。
ip addr / ifconfig — IPアドレス・NIC確認
EC2にSSH接続したら、まず ip addr(または ip a)でインターフェース情報を確認します。プライベートIPがVPCのサブネット設計どおりの範囲に入っているかを最初に把握しましょう。
# 全インターフェースのIP情報を表示
$ ip addr
# または短縮形
$ ip a出力例:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 state UP
inet 10.0.1.5/24 brd 10.0.1.255 scope global dynamic eth0出力の読み方は以下のとおりです。
| フィールド | 意味 |
|---|---|
| eth0 | インターフェース名(EC2ではeth0が一般的) |
| state UP | インターフェースが有効な状態 |
| inet 10.0.1.5/24 | IPv4アドレスとCIDRプレフィックス |
ifconfig は旧コマンドです。Amazon Linux 2023など最近のディストリビューションでは未インストールの場合があるため、ip addr を使うことを推奨します。
ip route / route — ルーティングテーブル確認
プライベートサブネット内のEC2でこのコマンドを実行し、デフォルトルートがNATゲートウェイを経由しているかを確認します。
# ルーティングテーブルを表示
$ ip route
# または短縮形
$ ip r
# 特定の宛先への経路を確認
$ ip route get 8.8.8.8出力例:
default via 10.0.1.1 dev eth0 proto dhcp src 10.0.1.5 metric 100
10.0.1.0/24 dev eth0 proto kernel scope link src 10.0.1.5
169.254.169.254 dev eth0 proto dhcp scope link1行目:default via 10.0.1.1 dev eth0 proto dhcp src 10.0.1.5 metric 100
「宛先がどのルートにも一致しないとき、10.0.1.1(VPCルーター)経由で出る」
| フィールド | 値 | 意味 |
|---|---|---|
default | — | 宛先が 0.0.0.0/0、つまりデフォルトルート |
via 10.0.1.1 | 10.0.1.1 | 次の転送先(ネクストホップ)=VPCルーター |
dev eth0 | eth0 | 使用するネットワークインターフェース |
proto dhcp | dhcp | このルートがDHCPによって自動設定されたことを示す |
src 10.0.1.5 | 10.0.1.5 | このEC2の送信元IPアドレス |
metric 100 | 100 | ルートの優先度(数値が低いほど優先) |
実際の動き: ping 8.8.8.8 や curl google.com のように、VPC外への通信はすべてこのルートが使われます。10.0.1.1(VPCルーター)に届いたパケットが、ルートテーブルの設定に従ってIGWまたはNATゲートウェイに転送されます。
2行目:10.0.1.0/24 dev eth0 proto kernel scope link src 10.0.1.5
「10.0.1.0/24 のアドレス宛ては、ルーターを経由せずeth0から直接届ける」
| フィールド | 値 | 意味 |
|---|---|---|
10.0.1.0/24 | — | このサブネット内のアドレス宛てのルート |
dev eth0 | eth0 | 使用するインターフェース |
proto kernel | kernel | OSカーネルが自動生成したルート(IPアドレスを設定すると自動で追加される) |
scope link | link | 同一リンク(同一サブネット)内で直接到達可能、ルーター不要 |
src 10.0.1.5 | 10.0.1.5 | 送信元IP |
実際の動き: 同じサブネット内の別EC2(例:10.0.1.10)への通信はVPCルーターを経由せず、直接eth0から届きます。via がないのはそのためです。
3行目:169.254.169.254 dev eth0 proto dhcp scope link src 10.0.1.5
「169.254.169.254 宛ては eth0 から直接アクセスする(EC2メタデータサービス)」
| フィールド | 値 | 意味 |
|---|---|---|
169.254.169.254 | — | EC2インスタンスメタデータサービス(IMDS)のアドレス |
dev eth0 | eth0 | 使用するインターフェース |
proto dhcp | dhcp | DHCPによって自動設定 |
scope link | link | ルーターを経由せず直接到達 |
169.254.x.x はリンクローカルアドレスと呼ばれ、インターネットにもVPC内にも出ていかない特殊なアドレス帯です。curl http://169.254.169.254/latest/meta-data/ でEC2のインスタンスIDやIAMロール情報などを取得するときに使われます。
ping — 疎通確認(ICMP)
まず ping 8.8.8.8(IP指定)→ 次に ping google.com(ドメイン指定)の順に試すことで、ルーティング問題とDNS問題を切り分けられます。
# 4回だけ送信して止まる(IPアドレス指定:ルーティング確認)
$ ping -c 4 8.8.8.8
# ドメイン名で確認(DNS解決も同時にテスト)
$ ping -c 2 google.com正常時の出力例:
64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=1.25 ms
4 packets transmitted, 4 received, 0% packet loss主なオプションは以下のとおりです。
| オプション | 説明 |
|---|---|
| -c <回数> | 送信回数を指定(省略すると無限送信) |
| -i <秒> | 送信間隔 |
| -W <秒> | タイムアウト秒数 |
⚠️ pingが届かない ≠ ホストが死んでいる。セキュリティグループ(SG)でICMPを許可していない場合、ホストが稼働していてもpingは失敗します。
traceroute — 経路確認
プライベートサブネットのEC2から外部への通信が届かないとき、NATゲートウェイを経由しているかを確認します。hop1がVPCルーター、hop2がNATゲートウェイのIPになっていれば、ルート設定は正常です。
$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 10.0.1.1 (10.0.1.1) 0.3 ms <-- VPCルーター
2 52.95.xxx.xxx (52.95.xxx.xxx) 1.2 ms <-- NATゲートウェイ
3 54.239.xxx.xxx 8.5 ms <-- AWSネットワーク
4 * * * <-- 応答なし(フィルタされている)
5 8.8.8.8 (8.8.8.8) 12.1 ms
# TCPで確認(ICMPがブロックされている場合)
$ traceroute -T -p 443 google.com
nslookup / dig — DNS解決の確認
Route 53で設定したレコードの確認や、EC2間のプライベートDNS解決の検証に使います。SERVER に 10.0.0.2 と表示されれば AWS VPC DNSサーバーを使用中です。
dig詳細なDNS情報を取得(推奨)
# Aレコード(IPv4)を確認
$ dig google.com A
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 300 IN A 142.250.xxx.xxx
;; Query time: 1 msec
;; SERVER: 10.0.0.2#53(10.0.0.2) <-- DNSサーバーのIP
# Route 53のドメインを確認(ホスト名解決)
$ dig myapp.example.com A
# 特定のDNSサーバーに問い合わせ
$ dig @8.8.8.8 google.com
# 短縮表示(IPだけ見たい場合)
$ dig +short google.com
142.250.xxx.xxx🔑 AWSでの活用場面SERVER: 10.0.0.2 と表示されれば、AWSのVPC DNSサーバー(VPC CIDR + 2)を使っています。Route 53で設定したレコードが引けるかの確認、EC2間のプライベートDNS解決(例: ip-10-0-1-5.ap-northeast-1.compute.internal)の検証にも使います。
nslookupシンプルなDNS問い合わせ
$ nslookup google.com
Server: 10.0.0.2
Address: 10.0.0.2#53
Non-authoritative answer:
Name: google.com
Address: 142.250.xxx.xxx
# 逆引き(IPからドメインを調べる)
$ nslookup 10.0.1.5netstat / ss — ポート開放・接続状態の確認
EC2にNginxやMySQLを設定後、正しいポートでLISTENしているかを確認します。「OSレベルでポートが開いているか(ss)」と「SGで許可されているか」を分けて切り分けるのが重要です。
ss:ソケット情報を高速表示(推奨)
# 全TCPポートのLISTEN状態を確認(よく使う組み合わせ)
$ ss -tlnp
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=xxx))
LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=xxx))
LISTEN 0 128 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=xxx))
# 確立済みの接続を確認
$ ss -tnp
# 特定ポートの状態を確認(例: MySQL 3306)
$ ss -tlnp | grep 3306主なオプションは以下のとおりです。
| オプション | 説明 |
|---|---|
| -t | TCP接続のみ |
| -u | UDP接続のみ |
| -l | LISTENポートのみ |
| -n | 数値で表示(名前解決しない) |
| -p | プロセス名・PIDも表示 |
curl / wget — HTTP疎通・レスポンス確認
EC2メタデータの取得、プライベートサブネットからNAT経由のIP確認、ALBのDNS名でHTTPレスポンスが返るかの確認など、幅広い場面で活用します。
# ヘッダーのみ確認(-I)
$ curl -I https://example.com
HTTP/2 200
content-type: text/html; charset=UTF-8
server: nginx
...
# 詳細な接続情報(-v)→ SSL/TLSのデバッグに有効
$ curl -v https://example.com
# EC2のメタデータを取得
$ curl http://169.254.169.254/latest/meta-data/
ami-id
instance-id
instance-type
local-ipv4
public-ipv4
...
# 自分のパブリックIPを確認(EC2のパブリックIPまたはNATゲートウェイのIP)
$ curl ifconfig.me
52.68.xxx.xxx <-- EC2のパブリックIPまたはNATゲートウェイのIP
# タイムアウト付きリクエスト
$ curl --connect-timeout 5 -I http://10.0.2.10telnet / nc(netcat) — 特定ポートへの接続確認
WebサーバーEC2からRDS(MySQL: 3306)の接続確認や、踏み台からプライベートEC2のSSHポート(22)確認に有効です。「SGは開けたはずなのに繋がらない」の切り分けに最適なコマンドです。
# TCP接続確認(推奨:nc)
# -z: スキャンモード、-v: 詳細表示
$ nc -zv 10.0.2.10 3306
Connection to 10.0.2.10 3306 port [tcp/mysql] succeeded! ← 成功
$ nc -zv 10.0.2.10 22
nc: connect to 10.0.2.10 port 22 (tcp) failed: Connection refused ← 失敗
# タイムアウト付き
$ nc -zv -w 3 10.0.2.10 443
# telnet(旧コマンド)
$ telnet 10.0.2.10 80
Connected to 10.0.2.10. ← 接続成功⚠️ telnetは平文通信のため、ログイン用途での使用は禁止です。Amazon Linux 2023ではデフォルト未インストールの場合があります。ポート確認には nc を推奨します。
ssh — EC2への接続・鍵指定オプション
EC2への接続では秘密鍵ファイルの権限設定が重要です。踏み台サーバー経由の接続やSSHポートフォワーディングも覚えておくと実務で役立ちます。
# 基本的な接続
$ chmod 400 my-key.pem
$ ssh -i my-key.pem ec2-user@54.xxx.xxx.xxx
# 踏み台サーバー(Bastion)経由でプライベートEC2に接続(ProxyJump)
$ ssh -i my-key.pem
-J ec2-user@54.xxx.xxx.xxx
ec2-user@10.0.2.5
# SSHポートフォワーディング(RDSに直接アクセスしたいとき)
# → localhost:13306 でRDSに接続できるようになる
$ ssh -i my-key.pem
-L 13306:rds-endpoint.xxxxxxxxx.ap-northeast-1.rds.amazonaws.com:3306
ec2-user@54.xxx.xxx.xxx
# コマンド実行して即切断
$ ssh -i my-key.pem -T ec2-user@54.xxx.xxx.xxx "hostname"デフォルトユーザー名はOSによって異なります。
| OS | デフォルトユーザー名 |
|---|---|
| Amazon Linux 2 / 2023 | ec2-user |
| Ubuntu | ubuntu |
| Debian | admin |
主なオプションは以下のとおりです。
| オプション | 説明 |
|---|---|
| -i <鍵ファイル> | 秘密鍵ファイルを指定(.pem) |
| -p <ポート> | SSHポート指定(デフォルト22) |
| -J <踏み台> | 踏み台ホスト経由(ProxyJump) |
| -L <設定> | ローカルポートフォワーディング |
| -v | デバッグ出力(接続問題の調査に有効) |
⚠️ chmod 400 を忘れると「UNPROTECTED PRIVATE KEY FILE!」エラーが発生します。必ず接続前に権限を設定してください。
トラブルシュート時のコマンド活用フロー
「繋がらない」と感じたら、ネットワークの下の層から上の層へ順番に確認するのが基本です。以下のフローに沿って切り分けることで、問題の原因を素早く特定できます。
- NIC・IP確認(
ip addr):インターフェースがUPか、IPアドレスが正しいか - ルーティング確認(
ip route):デフォルトゲートウェイが設定されているか、NATルートがあるか - IP疎通確認(
ping 8.8.8.8):DNSを切り離してルーティングの疎通だけを確認 - DNS解決確認(
dig google.com):DNSサーバーが正しく設定され、名前解決できるか - ポート疎通確認(
nc -zv <IP> <Port>):セキュリティグループ・NACLで対象ポートが許可されているか - HTTP確認(
curl -v <URL>):Webサーバーがレスポンスを返しているか、TLS証明書は正常か - 経路確認(
traceroute <宛先>):どのホップで止まっているか経路上の障害点を特定
コマンド早見表(チートシート)
実務でよく使うコマンドをまとめたチートシートです。手元に置いておくとトラブルシュート時に役立ちます。
| 目的 | コマンド | AWSでの典型的な使い方 |
|---|---|---|
| IPアドレス確認 | ip addr | EC2のプライベートIPを確認 |
| ルーティング確認 | ip route | デフォルトGW・NATルートの確認 |
| IP疎通確認 | ping -c 4 8.8.8.8 | インターネット疎通・NAT動作確認 |
| 経路確認 | traceroute 8.8.8.8 | NATゲートウェイ経由の経路確認 |
| DNS確認 | dig google.com | Route 53レコード・VPC DNS確認 |
| ポート確認 | ss -tlnp | Nginx・MySQLのLISTEN確認 |
| HTTP疎通確認 | curl -I https://... | ALB・EC2のレスポンス確認 |
| メタデータ取得 | curl 169.254.169.254/latest/meta-data/ | インスタンスID・IPの取得 |
| NAT IP確認 | curl ifconfig.me | 送信元グローバルIPの確認 |
| ポート接続確認 | nc -zv <IP> <Port> | RDS/Redisへの接続確認 |
| EC2接続 | ssh -i key.pem ec2-user@IP | EC2への標準SSH接続 |
| 踏み台経由接続 | ssh -J bastion ec2-user@priv-IP | プライベートEC2への接続 |


コメント