做網站接案一定都會收到客戶傳來這句話：「網站打不開了，幫我看一下。」
這時候，我通常會直接丟出我寫的工具網址：check.yao-huei.com，請客戶把有問題的網址貼上去、按下「診斷」，幾秒鐘內就能拿到一份完整的網頁基礎健檢報告。
內容導覽
▍ 為什麼寫這個工具？為了解救「重複排查」的痛點
接案多年，遇過千奇百怪的「網站掛了」情境。但客戶通常不是工程師，很難精確描述到底是哪裡出問題——可能是 DNS 沒有生效、SSL 憑證過期、伺服器拋出 500 錯誤、CDN 快取卡住，甚至往往只是他自己電腦的各種問題。
在過去要釐清這些基礎建設層問題，必須大費周章打開好幾個工具交互驗證：
- • 查 DNS 解析：必須下
dig、nslookup指令，或打開 dnschecker.org。 - • 查 SSL 憑證：去跑 SSL Labs 測試，或者在瀏覽器狂點網址列的鎖頭。
- • 查 HTTP 狀態：用
curl -I指令打請求，或者打開 Postman。 - • 查 網站架構：看 curl 的 Response Header，或去查 builtwith.com 看標籤。
這些工具介面各自獨立、輸出格式也五花八門，每次要把零碎的資訊拼湊出完整的問題輪廓，都需要耗費不少時間。特別是遇到客戶十萬火急的求救時，這套繁瑣的流程根本緩不濟急。既然如此，不如自己寫一個按鈕，把所有的核心檢查全部整合在一起！
▍ check.yao-huei.com 會檢查哪些核心項目？
1. DNS 解析紀錄
一鍵列出 A、AAAA、CNAME、NS 記錄。最常見的錯誤就是「網域的 NS 改了，但對應的 A 記錄忘記設定」，或者「CNAME 誤指到錯誤的目的地」。透過這份報告，能第一時間判斷網域有沒有正確解析到目標 IP。
2. SSL 憑證狀態
自動驗證憑證的有效性、發行機構與到期日。實務上最常發生的災情，就是 Let’s Encrypt 的自動續約腳本突然失效，導致憑證過期、瀏覽器跳出紅色不安全警告，站長卻毫無察覺。診斷報告會直觀顯示距離過期還剩幾天，並在到期前 14 天內主動跳出警告提示。
3. HTTP 回應與重導向鏈
完整顯示 HTTP 狀態碼、回應時間與「重導向鏈（Redirect Chain）軌跡」。如果遇到了 500、502 或 503 等伺服器錯誤，能立馬判定是後端 PHP 崩潰、Nginx 上游沒響應，還是主機商的防火牆在搞鬼。此外，重導向鏈追蹤也非常好用，能一眼看出網站是否存在無謂的多次跳轉（例如：HTTP → HTTPS → www → 帶斜線結尾）。
4. 基礎網頁架構偵測
自動辨識該網站是否有使用 CDN（如 Cloudflare、Akamai 等）、底層伺服器類型（Nginx、Apache、LiteSpeed）以及技術框架（WordPress 或各大網頁 Framework）。這對於工程師臨時要接手或排查客戶的「舊網站」特別方便，第一秒就能掌握對方的環境結構。
▍ 殺手級功能：搭配 AI 工具的省時工作流
除了上述的基礎檢查最方便的就是：「複製 AI 診斷報告」。
按下去之後，系統會將整份健檢報告壓縮、轉換成高度結構化的純文字，你可以直接貼給 ChatGPT、Claude 或 Gemini 等 AI 助手，並搭配以下指令請它提供修復建議：
這是我網站的健檢報告，請幫我看看目前問題出在哪裡？應該如何修復？💡 對工程師與客戶的雙重優勢
- • 對非技術客戶而言：不用強迫自己去搞懂 dig 或伺服器狀態碼，把 AI 回覆的「白話文修復指南」直接轉貼給工程師即可。
- • 對維運工程師而言：省去了看雜亂截圖的時間，AI 閱讀結構化資料非常精準，能立刻點出「去檢查特定 Nginx 設定」或「網域 NS 記錄有誤」等核心關鍵。
▍ 踩坑提醒與實務開發建議
在將這個工具納入你的維運工具箱之前，請先留意它的局限性與設計邊界：
一、這是一個「網路與基礎設施」快檢工具，它不檢查以下項目：
- • 前端 CSS 跑版或 Layout 異常（這需要搭配瀏覽器開發者工具 DevTools）。
- • JavaScript 執行報錯或點擊沒反應（需要檢查瀏覽器的 Console 面板）。
- • WordPress 等後台系統的外掛衝突（這必須登入後台或透過 FTP 關閉外掛進行測試）。
- • SEO 排名衰退與檢索問題（請查閱 Google Search Console）。
- • 網站內頁是否被注入惡意腳本（本工具僅針對網站首頁進行請求與連線驗證）。
二、隱私與紀錄儲存原則
本工具不會主動儲存或紀錄使用者的查詢歷史。然而，由於任何網路診斷工具本質上都是發送網路請求，因此 DNS 與 HTTP 請求難免會短暫留在中間行經的網路節點日誌（Log）中。如果您的目標網站屬於高度敏感的企業內網或測試機（Staging 站），且不希望任何中介設備留下軌跡，建議回歸傳統做法，在本機端使用本地的 dig 與 curl 手動查詢。
三、當主機商封鎖自動化請求時的解法
部分主機商或開啟了嚴格安全模式的 CDN（特別是 Cloudflare 嚴格模式），會將短時間內重複出現的自動化 HTTP HEAD 請求視為異常流量並實施攔截。如果您在診斷時頻繁遇到 403 Forbidden 或 connection refused，這通常代表請求被目標主機的防火牆擋下了。建議先透過一般瀏覽器開圖確認網站本身是否存活，並靜待 5 分鐘後再重新嘗試診斷。
四、它不能取代定時主動監控（Uptime Monitor）
請記住，check.yao-huei.com 是一個完全手動觸發的即時快檢工具，它不會定時幫你自動探測網站狀態。如果你需要的是 24 小時不間斷、一斷線就發送簡訊或 Slack 通知的主動監測系統，請去選擇 Uptime Robot 或 Better Stack 這一類專業的監控服務。這個工具的定位非常單純：「當人類在面對網站突發問題的當下，能用最快、最不費力的方式，一鍵拿到最完整的健檢報告。」
