先限定這張路線圖的情境
本圖描述使用 HTTP/1.1 或 HTTP/2、需要新連線的 HTTPS 情境。瀏覽器可能已快取 DNS 或重用連線；HTTP/3 使用 QUIC 而不是 TCP。因此這是理解責任的模型，不是每次點連結都必定重做的固定步驟。
URL 中的主機名稱幫助尋找目的地，路徑則識別該服務上的資源。https://docs.example.test/guide/ 中，docs.example.test 是主機，/guide/ 是路徑。它們解決不同問題。
四層各自提供什麼
DNS 取得名稱對應的資源紀錄；TCP 在這個情境建立可靠的位元組傳輸；TLS 協商保護通訊並驗證適當的對端身分；HTTP 表達方法、路徑、狀態與內容。名稱解析成功不代表 TCP 一定可達，TCP 成功也不代表網站授權已通過。
每一層都可能有自己的失敗。名稱不存在、連線逾時、憑證不符與 HTTP 404 是不同證據；把它們都叫「網路壞掉」會讓下一步變得模糊。
延伸閱讀：RFC 1034: Domain names, concepts and facilities·MDN: Transport Layer Security·MDN: Overview of HTTP
先看最接近的失敗證據
若已收到 HTTP 404，代表至少有某個 HTTP 服務回應該次請求；下一步先核對主機、路徑與路由配置。這不保證回應來自你預期的來源，尤其有代理或快取時，仍要核對脈絡。
若瀏覽器出現憑證安全警告，應核對身分、時間與設定並交由負責人處理，不靠略過警告完成測試。排錯的目標是找到可驗證原因，並保留安全界線。
例子：有 404，就先看路徑
合成紀錄依序是 DNS resolved、TCP connected、TLS verified、GET /guied/ → 404。預期網址其實是 /guide/。
既然已有 HTTP 回應，先核對拼字與路由比重新假設 DNS 完全失敗更直接。修改後仍需真正取得正確回應，不能只因路徑看起來對就宣稱已修復。
判斷：先修正可觀察的路徑錯字，再驗證狀態與內容。
離線練習：三筆錯誤的下一步
只使用合成文字紀錄，不發出網路請求或修改 DNS。
- 列出 A: name not found、B: certificate mismatch、C: HTTP 404。
- 每列寫最相關的層與一個下一步。
- 為 C 補上一句不能直接推論的事情，例如「整個網域不存在」。
預期結果
A 核對名稱與 DNS；B 核對憑證身分與設定，不略過警告；C 核對主機、路徑與路由。
自行檢核
若改用 HTTP/3，哪個傳輸協定名稱需要更新？
結束與清理
保存分層筆記，沒有網路設定需要回復。