Linuxで「つながらない」ときの調べ方｜ping・ss・curl -v・digで切り分ける【初心者向け】

2026年9月17日
Linux

前の記事では、「容量がいっぱい」「重い」ときの調べ方を学びました。今回は、サーバーでよく起きるもう1つの「困った」、つながらないときの調べ方です。

よくあるのが、n8n（＝画面上で「ノード」というブロックをつないで、自動化の流れを作れるツール）から自分の API にアクセスできなくなったとき、「ネットワークがおかしい」と思いこんで、ルーターを再起動したり、設定を書きかえたりしてしまうパターンです。私も最初は、こういう遠回りで時間を溶かしがちでした。最後に curl -v を打ってみたら「Connection refused」で、原因は API（＝プログラム同士がデータをやりとりするための窓口）のプログラムが止まっていただけ、ということもあります。最初に正しい順番で調べれば、すぐに終わる話です。

この記事では、自分のパソコンの中に小さな Web サーバーを立てて、わざと「つながらない」状態を3種類作ります。エラーの文の違いから、どこで止まっているかを見分ける練習をしましょう。

💡
この記事でわかること
  • 「つながらない」を、内側から外側へ順番に切り分ける考え方
  • ping・ip で、自分の足もとと経路を確かめる方法
  • getent・dig で、名前解決（DNS）を確かめる方法
  • ss で、ポート（＝1台のコンピューターの中で、どのサービスにつなぐかを分ける番号）で待っているプログラムを確かめる方法
  • curl -v のエラーの文から、原因の場所を見分ける方法
🔰
この記事の前提
  • IP アドレス・ポート・DNS（＝ドメイン名を IP アドレスに置きかえる、インターネットの電話帳のようなしくみ）のざっくりした意味がわかる
  • curl で Web ページを取ってきたことがある
  • sudo と apt を使える

まだの方は、前の記事「Linuxで「容量がいっぱい」「重い」を調べる｜df・du・free・top【初心者向け】」から読むのがおすすめです。IP アドレスやポートについては「Linuxのネットワークの基本｜IPアドレス・ポート・DNSをざっくり理解【初心者向け】」でくわしく説明しています。

💡
用語メモ
  • HTTP：ブラウザや curl が Web サーバーとやりとりするときの決まり
  • awk：行を列に分けて、集計や取り出しをするコマンド
  • コンテナ：アプリと、動かすのに必要なものをひとまとめにした箱。Docker で動かします
  • 待ち受け（リッスン）：プログラムが、決まったポートで通信が来るのを待っている状態

用語で迷ったら、連載のまとめ記事の「よく出てくる用語ミニ辞典」でも確かめられます。

結論：内側から外側へ、1段ずつ確かめる

確かめる段 コマンド うまくいかないときの表示の例
① 自分の足もと ping -c 3 127.0.0.1、ip route default の行がない
② 名前解決（DNS） getent hosts 名前、dig 名前 Could not resolve host
③ 相手まで届くか ping -c 3 名前 100% packet loss
④ ポートで待っているか ss -tln、curl -v Connection refused
⑤ 途中でさえぎられていないか curl -v --max-time 5 Connection timed out
⑥ アプリの返事 curl -v の HTTP の数字 404・500 など

「つながらない」の切り分けの階段

準備：練習用のディレクトリと道具

  • 1
  • 2
  • 3
  • 4
  • 5
mkdir -p ~/linux-practice/net-trouble-test
cd ~/linux-practice/net-trouble-test
sudo apt update
sudo apt install bind9-dnsutils
dig -v

🖥️
この記事の出力例について

ここから先の出力例は、Debian 13での実行例です（ユーザー名 kaito・パソコン名 demo のダミー環境）。UbuntuやWSL（＝Windows の中で Linux を動かせる、Microsoft のしくみ）では、表示が少し違うことがあります。

（例）

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
kaito@demo:~/linux-practice/net-trouble-test$ sudo apt update
Get:1 http://deb.debian.org/debian trixie InRelease [140 kB]
Get:2 http://deb.debian.org/debian trixie-updates InRelease [47.3 kB]
Get:3 http://deb.debian.org/debian-security trixie-security InRelease [43.4 kB]
Fetched 231 kB in 0s (4537 kB/s)
All packages are up to date.
kaito@demo:~/linux-practice/net-trouble-test$ sudo apt install bind9-dnsutils
Installing:
  bind9-dnsutils

Installing dependencies:
  bind9-host  libfstrm0     liblmdb0       libprotobuf-c1  libuv1t64
  bind9-libs  libjemalloc2  libmaxminddb0  liburcu8t64     libxml2

Suggested packages:
  mmdb-bin

Summary:
  Upgrading: 0, Installing: 11, Removing: 0, Not Upgrading: 0
  Download size: 2791 kB
  Space needed: 8279 kB / 107 GB available

Continue? [Y/n] Y
…（途中省略）…
Setting up bind9-dnsutils (1:9.20.30-1~deb13u1) ...
Processing triggers for man-db (2.13.1-1) ...
Processing triggers for libc-bin (2.41-12+deb13u4) ...
kaito@demo:~/linux-practice/net-trouble-test$ dig -v
DiG 9.20.30-1~deb13u1-Debian

検証環境（Debian 13）では、dig は最初は入っていませんでした。bind9-dnsutils と、必要な部品10個がいっしょに入り、合わせて11個になりました。途中の長い表示は省略しています。すでに入っている場合は、is already the newest version と表示されます。

dig は、DNS に名前を問い合わせる道具です。Debian では bind9-dnsutils というパッケージ（＝ソフトをインストールしやすいように、ひとまとめにしたもの）に入っています。

STEP 1：自分の足もとを確かめる

まず、自分自身（127.0.0.1）に ping を打ちます。ここで失敗するなら、ネットワークより前の問題です。

  • 1
  • 2
  • 3
ping -c 3 127.0.0.1
ip -br addr
ip route

（例）

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
kaito@demo:~/linux-practice/net-trouble-test$ ping -c 3 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=127 time=0.054 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=127 time=0.021 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=127 time=0.019 ms

--- 127.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2027ms
rtt min/avg/max/mdev = 0.019/0.031/0.054/0.016 ms
kaito@demo:~/linux-practice/net-trouble-test$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UNKNOWN        192.168.1.20/24 fe80::a1b2:c3ff:fed4:e5f6/64
kaito@demo:~/linux-practice/net-trouble-test$ ip route
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.20

IP アドレスとネットワークの名前（eth0）は、ダミーに置き換えています。ttl=127 の数字は、検証環境（コンテナ）の設定によるもので、ふつうは ttl=64 と表示されることが多いです。

ip route の default via … は、「外に出るときは、この出口（ルーター）を通る」という意味です。この行がないと、外のサーバーにはつながりません。

STEP 2：名前解決（DNS）を確かめる

ブラウザやコマンドで使う example.com のような名前は、まず DNS で IP アドレスに変換されます。ここで失敗すると、相手がどこにいるかすらわかりません。

  • 1
  • 2
  • 3
getent hosts example.com
dig example.com +short
dig kaito-nothing.invalid

（例）

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
kaito@demo:~/linux-practice/net-trouble-test$ getent hosts example.com
203.0.113.10    example.com
kaito@demo:~/linux-practice/net-trouble-test$ dig example.com +short
203.0.113.10
kaito@demo:~/linux-practice/net-trouble-test$ dig kaito-nothing.invalid

; <<>> DiG 9.20.30-1~deb13u1-Debian <<>> kaito-nothing.invalid
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50306
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;kaito-nothing.invalid.         IN      A

;; ANSWER SECTION:
kaito-nothing.invalid.  30      IN      A       203.0.113.10

;; Query time: 3 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Sun Nov 01 04:14:51 JST 2026
;; MSG SIZE  rcvd: 55

IP アドレスは、説明用のダミー（203.0.113.10・192.168.1.1）に置き換えています。

ふつうの回線では、この問い合わせは status: NXDOMAIN（「その名前は存在しません」という意味）になるのが一般的です。ただし、環境により異なります。検証環境の DNS は、存在しない名前にもアドレスを返す設定だったため、上のように status: NOERROR（ANSWER: 1）になりました。.invalid は、絶対に存在しない名前として決められている練習用の名前です。

getent hosts は、パソコンがふだん使うのと同じ方法（/etc/hosts を見てから DNS に聞く）で調べます。dig は DNS に直接聞きます。両方の結果が違うときは、/etc/hosts に古い書き込みが残っていないか疑いましょう。

STEP 3：相手まで届くかを確かめる

  • 1
ping -c 3 example.com

（例）

  • 1
  • 2
  • 3
  • 4
  • 5
kaito@demo:~/linux-practice/net-trouble-test$ ping -c 3 example.com
PING example.com (203.0.113.10) 56(84) bytes of data.

--- example.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2039ms

検証環境では、外への ping が通らない制限があり、100% packet loss になりました。

ping に返事がなくても、すぐに「つながらない」とは決めつけないでください。セキュリティのために、ping に返事をしない設定のサーバーもたくさんあります。Web サイトなら、次の curl -v で確かめるのが確実です。

STEP 4：curl -v で「どこまで進んだか」を見る

-v（verbose）をつけると、curl が何をしているかを1行ずつ見せてくれます。

  • 1
curl -v https://example.com -o /dev/null

（例）

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
kaito@demo:~/linux-practice/net-trouble-test$ curl -v https://example.com -o /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Host example.com:443 was resolved.
* IPv6: (none)
* IPv4: 203.0.113.10
*   Trying 203.0.113.10:443...
…（途中省略）…
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519MLKEM768 / id-ecPublicKey
* ALPN: server accepted h2
…（途中省略）…
* Connected to example.com (203.0.113.10) port 443
* using HTTP/2
…（途中省略）…
> GET / HTTP/2
> Host: example.com
> User-Agent: curl/8.14.1
> Accept: */*
…（途中省略）…
< HTTP/2 200
< date: Sat, 31 Oct 2026 19:15:06 GMT
…（途中省略）…
* Connection #0 to host example.com left intact

とても長い出力なので、大事な行だけを残して途中を省略しています。was resolved（名前解決できた）→ Trying（つなぎに行く）→ SSL connection using（暗号化の準備ができた）→ Connected to（つながった）→ < HTTP/2 200（相手のアプリが「OK」と返した）の順に進んでいます。IP アドレスはダミーに置き換えています。

Debian 13での実行画面

行の始まり 意味
* curl の作業メモ（名前解決・接続・暗号化など）
> こちらから送った内容
< 相手から返ってきた内容

名前解決に失敗するときの例です。

  • 1
curl -v https://kaito-nothing.invalid

（例）

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
kaito@demo:~/linux-practice/net-trouble-test$ curl -v https://kaito-nothing.invalid
* Host kaito-nothing.invalid:443 was resolved.
* IPv6: (none)
* IPv4: 203.0.113.10
*   Trying 203.0.113.10:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS alert, decode error (562):
* TLS connect error: error:0A000126:SSL routines::unexpected eof while reading
* closing connection #0
curl: (35) TLS connect error: error:0A000126:SSL routines::unexpected eof while reading

ふつうの回線では、名前が見つからないので curl: (6) Could not resolve host: kaito-nothing.invalid になるのが一般的です。ただし、環境により異なります。検証環境では、DNS が存在しない名前にもアドレスを返したため、名前解決は「できてしまい」、そのアドレスとの暗号化の途中で失敗して curl: (35) TLS connect error になりました。

このように、エラーの文が予想とちがうときは、was resolved や Trying の行を見て、「どこまで進んだか」を確かめるのが大切です。

STEP 5：小さなサーバーを立てて、3種類の「つながらない」を作る

自分のパソコンの中だけで動く Web サーバーを立てます。--bind 127.0.0.1 をつけているので、外のパソコンからはつながりません。

  • 1
  • 2
echo "kaito のテストページです" > index.html
python3 -m http.server 8000 --bind 127.0.0.1

（例）

  • 1
  • 2
kaito@demo:~/linux-practice/net-trouble-test$ python3 -m http.server 8000 --bind 127.0.0.1
Serving HTTP on 127.0.0.1 port 8000 (http://127.0.0.1:8000/) ...

このターミナルはそのままにして、もう1つターミナルを開いて、ポートで待っているプログラムを確かめます。

  • 1
  • 2
ss -tln
ss -tln | grep 8000

（例）

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
kaito@demo:~$ ss -tln
State        Recv-Q       Send-Q             Local Address:Port             Peer Address:Port
LISTEN       0            5                      127.0.0.1:8000                  0.0.0.0:*
LISTEN       0            5                      127.0.0.1:3142                  0.0.0.0:*
LISTEN       0            20                     127.0.0.1:25                    0.0.0.0:*
LISTEN       0            20                         [::1]:25                       [::]:*
kaito@demo:~$ ss -tln | grep 8000
LISTEN 0      5          127.0.0.1:8000      0.0.0.0:*

127.0.0.1:3142 は、検証環境で使っている apt のダウンロード用の中継のものです。読者の環境では表示されません。:25 の2行は、Debian に最初から入っているメール配送のプログラム（exim4）です。どちらも 127.0.0.1 や [::1] だけで待っているので、外からは見えません。

ss の -t は TCP、-l は待ち受け中（LISTEN）、-n は数字のまま表示、という意味です。sudo ss -tlnp とすると、どのプログラムが待っているかも表示されます。

では、3種類のアクセスを試します。

  • 1
  • 2
  • 3
curl -v http://127.0.0.1:8000/
curl -v http://127.0.0.1:8001/
curl -v --max-time 5 http://192.0.2.1/

（例）

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
kaito@demo:~$ curl -v http://127.0.0.1:8000/
*   Trying 127.0.0.1:8000...
* Connected to 127.0.0.1 (127.0.0.1) port 8000
* using HTTP/1.x
> GET / HTTP/1.1
> Host: 127.0.0.1:8000
> User-Agent: curl/8.14.1
> Accept: */*
>
* Request completely sent off
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Server: SimpleHTTP/0.6 Python/3.13.5
< Date: Sat, 31 Oct 2026 19:15:16 GMT
< Content-type: text/html
< Content-Length: 34
< Last-Modified: Sat, 31 Oct 2026 19:15:09 GMT
<
kaito のテストページです
* shutting down connection #0
kaito@demo:~$ curl -v http://127.0.0.1:8001/
*   Trying 127.0.0.1:8001...
* connect to 127.0.0.1 port 8001 from 127.0.0.1 port 38140 failed: Connection refused
* Failed to connect to 127.0.0.1 port 8001 after 0 ms: Could not connect to server
* closing connection #0
curl: (7) Failed to connect to 127.0.0.1 port 8001 after 0 ms: Could not connect to server
kaito@demo:~$ curl -v --max-time 5 http://192.0.2.1/
*   Trying 192.0.2.1:80...
* Connection timed out after 5002 milliseconds
* closing connection #0
curl: (28) Connection timed out after 5002 milliseconds

1つ目は HTTP/1.0 200 OK のあとにページの中身が返ってきました。2つ目は Connection refused（誰も待っていない）で、最後の行は curl: (7) … Could not connect to server です。3つ目は curl: (28) Connection timed out after 5002 milliseconds で、5秒待ってあきらめています。

Debian 13での実行画面

192.0.2.1 は、説明用に決められた「どこにもつながらない」アドレスです。--max-time 5 で、5秒であきらめるようにしています。

エラーの文 何が起きているか 次に見るところ
Could not resolve host 名前から IP アドレスがわからない 名前のつづり、DNS、/etc/hosts
Connection refused 相手には届いたが、そのポートで誰も待っていない ポート番号、サービスが動いているか（ss・systemctl status）
Connection timed out 途中で返事がなくなった ファイアウォール、相手が止まっていないか、IP アドレス
HTTP の 404・500 など つながったが、アプリがエラーを返した URL のパス、アプリのログ

最初のターミナルを見ると、"GET / HTTP/1.1" 200 のようなアクセスの記録が出ているはずです。

（例）

  • 1
  • 2
  • 3
kaito@demo:~/linux-practice/net-trouble-test$ python3 -m http.server 8000 --bind 127.0.0.1
Serving HTTP on 127.0.0.1 port 8000 (http://127.0.0.1:8000/) ...
127.0.0.1 - - [01/Nov/2026 04:15:16] "GET / HTTP/1.1" 200 -

1つ目の curl のアクセスだけが記録されています。2つ目（ポート 8001）と3つ目（192.0.2.1）は、このサーバーには届いていないからです。サーバー側のログで「そもそも届いているか」を確かめるのも、大事な切り分けです。

💡
VPS で「外からだけつながらない」ときの、3つの壁

この記事は、自分のパソコンの中だけで練習しました。VPS（＝大きな物理サーバーを区切って作った、自分専用の仮想サーバーを、月額などで借りられるサービス）で「サーバーの中では curl が通るのに、自分の PC のブラウザからはつながらない」ときは、外側に向かって次の3つの壁を順に見ます。

  1. 待ち受けの場所：ss -tln の Local Address が 127.0.0.1:ポート なら、サーバーの中からしか見えません（この記事の STEP 5 と同じ形です）。外に見せるかどうかは、セキュリティ基礎の記事の表で確かめます。Docker（＝アプリを、必要なものごと「コンテナ」という箱に入れて動かす道具）で動かしているときは、-p 127.0.0.1:5678:5678 のように書いたかどうかも関係します（Docker 入門の記事と、VPS で n8n を動かす記事）。
  2. サーバーのファイアウォール（ufw）：sudo ufw status で、そのポートが許可されているかを見るだけにします（VPS の初期設定の記事）。Debian 13 の ufw（＝Debian・Ubuntu で使える、ファイアウォールをかんたんに設定するための道具）は、最初の設定で「外から入ってくるものは、返事をせずに捨てる」（DROP）になっています。そのため、許可していないポートは、返事が来ないまま Connection timed out になるのがふつうです（設定を変えていると、ちがう結果になることがあります）。
  3. VPS の管理画面のファイアウォール：VPS の会社によっては、管理画面にも別のファイアウォール（＝通信を、決めたルールで通したり止めたりする門番）があります。ここで閉じていても、サーバーの中からは何も見えません。あるかどうかは VPS の会社により異なります。

「1つずつ見て、1つずつ直す」のは、ここでも同じです。下の🚫の箱のとおり、ファイアウォールを止めて試すのはやめましょう。

検証では、ufw を入れたり動かしたりはせず、Debian 13 の ufw のパッケージ（0.36.2-9）をダウンロードして、最初の設定ファイル /etc/default/ufw の中身だけを読みました。command -v ufw; echo $? の 1 は、ufw が入っていないという意味です。

  • 1
  • 2
  • 3
  • 4
command -v ufw; echo $?
apt-get download ufw
ls
dpkg-deb --fsys-tarfile ufw_*.deb | tar -xO ./etc/default/ufw | grep -n "POLICY="

（例）

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
kaito@demo:~/linux-practice/net-trouble-test$ command -v ufw; echo $?
1
kaito@demo:~/linux-practice/net-trouble-test$ apt-get download ufw
Get:1 http://deb.debian.org/debian trixie/main amd64 ufw all 0.36.2-9 [169 kB]
Fetched 169 kB in 0s (7348 kB/s)
kaito@demo:~/linux-practice/net-trouble-test$ ls
ufw_0.36.2-9_all.deb
kaito@demo:~/linux-practice/net-trouble-test$ dpkg-deb --fsys-tarfile ufw_*.deb | tar -xO ./etc/default/ufw | grep -n "POLICY="
11:DEFAULT_INPUT_POLICY="DROP"
15:DEFAULT_OUTPUT_POLICY="ACCEPT"
19:DEFAULT_FORWARD_POLICY="DROP"
24:DEFAULT_APPLICATION_POLICY="SKIP"

11行目の DEFAULT_INPUT_POLICY="DROP" が「入ってくるものは捨てる」という設定です。捨てられたパケットには返事がないので、curl は時間切れまで待つことになります。

Debian 13での実行画面
🚫
つながらないときに、やってはいけないこと（文章だけで説明します）

「とりあえずファイアウォールを止めてみる」（sudo ufw disable や sudo iptables -F）は、サーバーを丸裸にする操作です。止めたまま忘れると、誰でも入れる状態になります。また、サーバーを --bind 0.0.0.0 で動かすと、同じネットワークや、場合によってはインターネット全体から見えるようになります。/etc/resolv.conf を手で書きかえるのも、別のしくみに上書きされたり、名前解決が全部止まったりする原因になります。他人のサーバーに対して、ポートを片っぱしから調べるツールを使うのもやめましょう。この記事のように、まずは見るだけのコマンドで原因の場所をしぼることが大切です。

🤖 詰まったらAIに聞こう：どこで止まっているかわからない

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
Linuxの初心者です。サーバー（またはAPI）につながらなくて困っています。
次の結果から、どの段階（名前解決・経路・ポート・ファイアウォール・アプリ）で
止まっていそうかと、次に確かめるコマンドを教えてください。

【つなぎたい相手】例：自分のVPSのn8n（ドメイン名は example.com に置き換え）
【curl -v の結果】ここに貼る
【dig 名前 +short の結果】ここに貼る
【ss -tln の結果（サーバー側）】ここに貼る
【直前にしたこと】例：ポート番号を変えた、サーバーを再起動した

🔒
AIに貼る前に：秘密情報やパスワードは貼らない

curl -v の結果には、Authorization や Cookie の行（ログインの合い言葉）が出ることがあります。この行は必ず消すか「＊＊＊」にしてください。サーバーの 本物の IP アドレスやドメイン名も、203.0.113.10 や example.com のようなダミーに置き換えてから貼りましょう。

後片づけ

最初のターミナルで Ctrl + C を押して、Web サーバーを止めます。そのあと、もう1つのターミナルで次を打ちます。

  • 1
  • 2
  • 3
  • 4
ss -tln | grep 8000
cd ~/linux-practice
rm -r net-trouble-test
ls

最初のターミナルで Ctrl + C を押すと、次のように表示されてサーバーが止まります。

（例）

  • 1
  • 2
^C
Keyboard interrupt received, exiting.

もう1つのターミナルの ss -tln | grep 8000 は、何も表示されませんでした（もう待っていない）。そのあとの片づけの結果です。

（例）

  • 1
  • 2
  • 3
  • 4
kaito@demo:~$ ss -tln | grep 8000
kaito@demo:~/linux-practice$ rm -r net-trouble-test
kaito@demo:~/linux-practice$ ls
archive-test  chmod-test  edit-test  find-test  grep-test  link-test  perm-test  redirect-test

net-trouble-test がなくなりました。ほかのフォルダは、これまでの記事の練習で作ったものです。

bind9-dnsutils は、このあとも調べものに使えるので、入れたままで大丈夫です。

よくある質問

Q. ping は 100% packet loss なのに、curl ではつながります。

ping の通信（ICMP）だけを止めている相手やネットワークがあります。ping が通らなくても、相手が止まっているとは限りません。Web サーバーなら、この記事の STEP 4 のように curl -v で確かめるのが確実です。

Q. WSL の中で動かしたサーバーに、Windows のブラウザからつながりません。

WSL の設定や Windows のバージョンによって、localhost（＝自分自身を指す特別な名前）でそのままつながる場合と、つながらない場合があります。環境により異なります。まず WSL の中で curl -v http://127.0.0.1:ポート/ が通るかを確かめ、通るなら WSL と Windows の間の設定を調べましょう。

Q. Connection refused と Connection timed out は、どちらが「近い」ですか？

refused は「相手のパソコンまでは届いたが、そのポートで誰も待っていない」ので、相手のすぐ近くまで来ています。timed out は「途中で返事がなくなった」ので、ファイアウォールや経路など、もっと手前で止まっていることがあります。この記事の STEP 5 のエラーの表が、そのまま次に見るところの目安になります。

まとめ

  • 「つながらない」は、内側から外側へ1段ずつ確かめる
  • 名前解決は getent hosts・dig。NXDOMAIN は「その名前はない」
  • ping に返事がなくても、つながらないとは限らない
  • curl -v のエラーの文で場所がわかる。resolve は DNS、refused はポート、timed out は途中
  • ss -tln で、どのポートで待っているかを見る。127.0.0.1 で待っているものは外から見えない
  • ファイアウォールを止めて試すのは、やめておく

次の記事では、sed と awk を学びます。ログの中から必要な列だけを取り出したり、数を数えたりする、1行の便利なコマンドです。

次に読む記事

関連する記事