在昨天的篇章中，我們掌握了主機運算資源的三大核心指標（CPU、記憶體與磁碟空間）。當硬體資源運作正常，伺服器最常面臨的另一大挑戰便是「網路連線異常」：

• 為什麼爬蟲程式抓不到外部 API？
• 為什麼外部用戶端連不上主機的特定服務？
• 無法確認是程式未啟動，還是連線請求遭到防火牆阻擋。

遇到網路問題時，盲目修改組態設定往往難以切中核心。今天我們將建立一套標準的排查順序，並透過 ping、ss、nc 與 curl 這四個核心工具，逐步釐清問題發生的環節。

1.網路問題診斷的排查順序
當網路通訊發生問題時，建議遵循由底層向應用層的排查流程：

[步驟 1: 網路連通層] 虛擬機能否連線外部網路？DNS 能否解析？
➔ ping
        │
[步驟 2: 本地監聽層] 目標服務是否有在指定的 Port 監聽？
➔ ss
        │
[步驟 3: 網路邊界層] 防火牆或連接埠轉發是否放行該連線？
➔ nc
        │
[步驟 4: 應用通訊層] 伺服器回傳的 HTTP 狀態碼為何？
➔ curl

依照此流程逐步檢查，能在短時間內精準定位是底層網路、本機服務還是中繼防火牆發生異常。

2.步驟一：基礎網路連通與 DNS 驗證（ping）
ping 是基於 ICMP 協定運作的工具，用來檢驗本機與目標伺服器之間的雙向連通性，也能同步確認網域名稱解析是否正常。

在終端機中執行：

ping -c 4 google.com

• 參數說明：Linux 的 ping 預設會持續發送封包，加上 -c 4 代表發送 4 次後自動結束。
• 結果判斷：
  • 正常：顯示 bytes from ... time=XX ms，代表外部網路與路徑暢通。
  • 封包丟失（100% packet loss）：網路連線中斷，或外部閘道器無法通行。
  • 無法解析網域名稱（Name or service not known）：通常代表系統 DNS 解析設定異常。此時可嘗試直接 ping 純 IP（例如 ping -c 4 8.8.8.8），若純 IP 能通但網址不通，即可確定問題出在 DNS 解析。

3.步驟二：檢視本機服務監聽狀態（ss）
當確定網路連通無誤後，下一步需確認目標服務是否已經成功在通訊埠（Port）上啟動並等待連線。
在 Ubuntu 等現代 Linux 發行版中，推薦使用效能與資訊更完整的 ss（Socket Statistics）：

sudo ss -tulpn

常用參數解析（tulpn）：

• -t (TCP)：僅顯示 TCP 協定相關連線。
• -u (UDP)：僅顯示 UDP 協定相關連線。
• -l (Listening)：僅列出處於「監聽（Listen）」狀態的通訊埠。
• -p (Process)：顯示佔用該埠號的程式名稱與 PID（需搭配 sudo 權限）。
• -n (Numeric)：直接以純數字顯示 IP 與 Port，不進行名稱反查以加快速度。

檢視輸出中的 Local Address:Port 欄位：

Netid  State   Local Address:Port   Peer Address:Port  Process                                
tcp    LISTEN  0.0.0.0:22           0.0.0.0:*          users:(("sshd",pid=812))          
tcp    LISTEN  127.0.0.1:5000       0.0.0.0:*          users:(("python3",pid=1420))

• 0.0.0.0:22：代表服務綁定在所有可用的網路介面上，任何外部主機能連到此主機的 IP，皆可嘗試連入該 Port。
• 127.0.0.1:5000：代表服務僅監聽在本機回環介面（localhost）。外部設備無論網路如何配置皆無法存取，僅供伺服器本機內部程式呼叫。若需對外提供服務，需將程式組態中的監聽 IP 改為 0.0.0.0。

4.步驟三：檢測通訊埠連通與防火牆狀態（nc）
若服務確實有在監聽，但外部主機依舊無法連入，通常是中間的網路防護機制（如 UFW 防火牆或虛擬機連接埠轉發）未放行。

可使用 nc（netcat） 進行快速的埠號探針測試：

nc -zv 127.0.0.1 22

• -z：僅測試連線狀態，不發送任何資料 payload。
• -v：輸出詳細的連線結果。

• 狀態判讀：
  • succeeded!：通訊埠暢通且服務正常響應。
  • Connection refused：網路路徑通暢，但目標通訊埠上目前沒有任何服務在監聽。
  • Timed out：連線逾時，通常代表封包被防火牆（如 UFW）直接丟棄，需檢視防火牆規則（sudo ufw status）。

5.步驟四：應用層 HTTP 與 API 通訊測試（curl）
當通訊埠已可連通，但程式抓取資料仍失敗時，應使用命令列工具 curl 直接模擬請求，檢視應用層的回應細節。

(1)僅取得回應標頭（Header）
以檢測外部 API 為例：

curl -I https://api.coingecko.com/api/v3/ping

• -I：僅下載 HTTP Header，適合快速確認狀態碼：
  • 200 OK：服務與網路均正常。
  • 403 Forbidden / 429 Too Many Requests：通常代表觸發了目標 API 的限流或阻擋機制。

(2)詳細交握排查（Verbose 模式）
若連線發生異常或中斷，加上 -v 檢視完整交握過程：

curl -v https://api.coingecko.com/api/v3/ping

輸出會完整呈現 DNS 解析結果、TCP 三向交握、TLS/SSL 憑證驗證歷程，以及送出的 Request 與收到的 Response，有助於找出具體卡在何處。

|明日目標：在排除網路與硬體層級的異常後，明天我們將探討如何使用 journalctl 配合時間篩選與關鍵字過濾，在系統日誌中定位程式異常終止與系統報錯的根本原因。|