MENU

DNSは引けるのに通信できない原因と対処法｜切り分け手順を徹底解説

コマンド編
  • URLをコピーしました！

「名前解決はできているのに通信できない」
「digやnslookupは成功するが、curlやncが失敗する」
「pingは通るのにアプリ通信だけNG」

このトラブルは現場で非常に発生頻度が高く、かつ DNSに気を取られて本質的な原因を見落としやすいのが特徴です。

本記事では「DNSは正常だが通信できない」ケース全体の切り分け手順を解説します。
特定ポートのみ通信できない場合は、別記事で詳しく解説しています。

あわせて読みたい
特定ポートだけ繋がらない原因｜DNSは引けるのに通信できない時の対処法 「DNSは正常に引ける」「pingも通る」「80番は通るのに443番だけNG」「同じIPなのにポートによって結果が違う」 この症状はネットワーク・OS・ミドルウェア・LBの どこ…

🔎 実務での切り分け順を知りたい方へ
ログ確認・リソース確認・ネットワーク確認など、Linux障害対応の基本フローを整理したまとめ記事はこちら。
▶ 症状別チェックリストと原因・対処の総まとめ

目次

まず結論：DNSが引ける＝通信できる、ではない

DNSはあくまでIPアドレスを引くだけです。

  • IPに到達できるか
  • ポートが開いているか
  • 通信が途中で落とされていないか

はDNSとは別問題です。

切り分け全体フロー（最短ルート）

  1. 名前解決の結果確認（本当に正しいIPか）
  2. IPレベル疎通（ICMP）
  3. ポート疎通（TCP/UDP）
  4. クライアント側制御（FW / SELinux）
  5. 経路・LB・NAT
  6. サーバ／アプリ側制御

以下、この順で具体コマンド＋対策を解説します。

① DNS結果が「本当に正しいIP」か確認

まずはDNS結果を鵜呑みにしないことが重要です。

# DNS結果確認
dig example.com

# glibc経由での確認
getent hosts example.com

以下のポイントを確認します。

  • 期待しているIPか
  • LBのIPではないか
  • IPv6（AAAA）が優先されていないか

ありがちな落とし穴

  • 古いIPが返ってきている
  • IPv6が引けるが通信できない

対策

  • A / AAAA レコードを分けて確認
  • 一時的にIPv4指定で検証
curl -4 http://example.com
あわせて読みたい
curl: (7) Failed to connect の解決方法 はじめに LinuxやMacでHTTPリクエストを確認する際によく使われる curl コマンドですが、実行したときに以下のエラーが出ることがあります。 curl: (7) Failed to conne…

② IPレベル疎通（ping）が通るか

DNSが引けたIPに対して、まずICMP疎通を確認します。

ping 93.184.216.34

結果の解釈

  • 通る → 次へ
  • 通らない → 経路 or FWの可能性大

※ pingを落としている環境もあるため、通らない＝即NGではない点に注意。

あわせて読みたい
ping は通るのにブラウザでアクセスできない原因と対処方法 Linuxサーバにアクセスできないとき、まず多くの人が試すのが ping コマンドです。 ping example.com これで応答が返ってくれば「ネットワークは生きている」と安心しま…

③ ポート疎通確認（ここが一番重要）

pingが通っても、ポートが閉じていれば通信できません。

# TCP疎通確認
nc -vz 93.184.216.34 443

# curlで実通信確認
curl -v http://example.com

典型的な失敗パターン

  • 接続タイムアウト → FW / 経路
  • 即切断 → アプリ or LB

対策

  • ポート番号が正しいか再確認
  • サーバ側でLISTENしているか確認

④ クライアント側のFirewall確認

意外と多いのが送信側FWです。

# firewalld確認
firewall-cmd --list-all

# iptables確認
iptables -L -n

チェックポイント

  • OUTPUTが制限されていないか
  • 特定ポートだけ落としていないか

対策

  • 一時的にFW無効化して切り分け
systemctl stop firewalld
あわせて読みたい
firewalld でポートが開かないときの対処方法 Linux サーバでサービスを公開しようとして firewalld を設定したのに、外部からアクセスできない…。そんなときに確認すべきポイントをまとめます。 🔎 実務での…

⑤ SELinuxによる通信ブロック

SELinuxはpingやDNSは通るがアプリ通信だけNGを引き起こします。

確認

getenforce

AVCログ確認

ausearch -m AVC -ts recent

対策

  • 一時的にPermissiveで確認
setenforce 0

Permissiveで通信できるならSELinuxが原因です。

あわせて読みたい
firewalldとSELinuxの役割の違い【混同しがちな通信制御を完全整理】 Linuxサーバーで通信トラブルが起きた際、 firewalld（iptables）とSELinuxの役割を混同していると、 切り分けに時間がかかり、誤った対処をしてしまいがちです。 本記…
あわせて読みたい
SELinuxポリシー設計のアンチパターン集【やってはいけない設計】 SELinuxは正しく設計すれば非常に強力ですが、 設計を誤ると「無効化したくなる存在」になります。 本記事では、現場で繰り返されてきた SELinuxポリシー設計のアンチパ…

⑥ 経路・NAT・LBの問題

DNSが引けても、経路が通っていないケースがあります。

# 経路確認
ip route get 93.184.216.34

# traceroute
traceroute 93.184.216.34

よくある原因

  • 戻り通信が別経路
  • NAT設定ミス
  • LBのidle timeout

対策

  • 送信・戻り経路の対称性確認
  • LB設定（idle timeout / health check）確認
あわせて読みたい
LB idle timeoutとアプリKeepAlive設計の落とし穴 ロードバランサ（LB）配下のシステムで、「通信が突然切れる」「一定時間後にRSTが返る」「再接続が頻発する」といった問題が発生する場合、LBのidle timeoutとアプリの…

⑦ サーバ・アプリ側で拒否されている

クライアント側が正常でも、サーバ側が拒否している場合があります。

確認

  • サーバFW
  • アプリのlistenアドレス
  • 最大接続数
# サーバ側LISTEN確認
ss -lntp

典型例

  • 127.0.0.1でのみLISTEN
  • 接続数上限で拒否

即解決につながるチェックリスト

  • DNS結果は正しいIPか
  • IPv6が優先されていないか
  • ポート疎通は通るか
  • 送信側FW / SELinux
  • 経路・LB・NAT
  • サーバ側LISTEN状態

まとめ

「DNSは引けるが通信できない」問題は、

  • DNSに原因はない
  • レイヤを順番に潰すのが最短

という特徴があります。

IP → ポート → 制御 → 経路の順で切り分ければ、 ほぼ確実に原因へ辿り着けます。

あわせて読みたい
Linuxで名前解決が不安定になる原因（resolv.conf以外） 「pingは通るのに名前解決だけ失敗する」「たまに名前解決できるが、再現性が低い」「resolv.confは正しいのにDNSエラーが出る」 このようなトラブルは、resolv.conf以…
あわせて読みたい
RSTが多発する時の原因と切り分け はじめに TCP通信において RST（Reset）パケットが多発する 状態は、「通信が強制的に切断されている」ことを意味します。 RSTは 正常系ではほぼ出ない ため、 アプリ障…
コマンド編
目次