← Systems Foundations

LINUX CORE · 85

Listener / localhost / 0.0.0.0 / curl：Process 活著不代表 Port 可達

Server debugging 最重要的切法之一：process 是否存在、是否 listen 正確 address/port、local request 是否成功、外部 network 是否能到達。不要一看到「網站連不上」就先怪 DNS。

Learning outcomes

1. Process 必須 bind/listen

Node process
  ↓ bind
127.0.0.1:3000
  ↓ listen
waiting for connections

Process 存在，不代表它有 listener；listener 存在，也不代表 Internet 能到。

2. 127.0.0.1 vs 0.0.0.0

127.0.0.1:3000
  local loopback only

0.0.0.0:3000
  all IPv4 interfaces

0.0.0.0 是 bind address 的概念，不是 client 要拿來瀏覽的遠端 IP。

3. ss 看 listener evidence

ss -lntp

LISTEN 0 511
127.0.0.1:3000
users:(("node",pid=4217))

這能把 port 對回 process PID。

4. curl 先測 local

curl -i   http://127.0.0.1:3000/health

Local curl 都失敗時，先修 app/listener；不要直接查 DNS、CDN、public firewall。

5. 從內到外排查

process
  ↓
listener
  ↓
local curl
  ↓
host firewall
  ↓
reverse proxy
  ↓
cloud/network rules
  ↓
DNS/public URL

這就是「最後成功 / 第一失敗」的 network 版本。

Project checkpoint：Server Workspace v5

Course API 綁 127.0.0.1，再改 0.0.0.0。每次用 ss/curl 記錄差異，最後加 reverse proxy 概念層。

ss -lntp
curl -i http://127.0.0.1:3000/health
curl -i http://SERVER_IP:3000/health

Debug evidence：外部連不上、local curl 200

這證明 application/listener 至少在本機可工作。下一個 hypothesis 應移到 bind interface、firewall、security group、proxy、routing，而不是繼續重寫 app handler。

Knowledge check

  1. Process 活著為何不等於 port 可達？
  2. 0.0.0.0 和 127.0.0.1 bind 差在哪？
  3. Local curl 200 能排除哪些問題？
  4. 畫出 server request 從 process 到 public DNS 的診斷順序。