多數人打開一個網站卻卡在轉圈圈，或跳出一串看不懂的英文代碼時，第一個念頭通常是「這個網站是不是掛了」。但「無法連上這個網站」這件事，原因其實分成好幾種完全不相干的情況，問題可能出在你自己的電腦或路由器，也可能是對方網域到期、主機資源用光，甚至是網站方自己設下的安全機制，把你判定成可疑流量擋在外面。
這幾種原因彼此獨立，判斷方式也完全不一樣。用查 DNS 的方法去處理一個過期的網域，或拿清快取的招式去解防火牆擋下的連線，只會愈查愈沒方向。你如果只是路過，只想確認這個網站是不是真的收掉了；但如果是要負責把它修好的站長，接下來該做的事也不一樣。
分清楚自己卡在哪一段，才知道該挑哪套方法查，不必把後面每一種可能都走一遍。
先分辨連不上是自己端還是網站端的問題
打不開一個網站的原因，最先要分成兩種立場來看。如果你只是想確認這個網站背後的品牌或商家是不是還在，做完基本判斷就夠了，不需要往下深究技術細節；但如果你是要對這個網站負責、動手把它修好的人，才需要往後面每一個原因逐一排查。
不管是哪一種立場，第一步都一樣，先確認問題出在你自己這端，還是網站那一端。做法很直接，有三種：換一個網路環境、換一台裝置，或請人在別的地方幫忙開同一個網址，只要有一個打得開，問題就是你這端的網路或裝置出狀況；三種方式都打不開，才代表問題真的出在網站或它背後的主機。後面幾節列的原因彼此獨立，不用照順序全部查一遍，確定是哪一段出問題，直接跳去對應那一節就好。
換個網路或裝置就能分辨問題出在自己端還是對方端
具體做法可以照幾個步驟走。先把手機的 Wi-Fi 關掉，切成行動網路（4G 或 5G）再打開同一個網址；如果原本在電腦上打不開，換一台平板或手機試試看；如果身邊剛好有人在別的縣市甚至國外，也可以請對方直接幫忙開一次同一個連結。
這三種測試只要有一個成功，代表問題出在你自己這端，可能是 Wi-Fi 分享器當機、DNS 快取記住了舊資料，或是你的裝置本身有問題，接下來就從自己這一端著手處理。如果三種方式全部都打不開，尤其是連異地的朋友都反映一樣的畫面，問題大概率不在你身上，而是網站本身或它背後的主機出了狀況，接下來要往網域、主機、憑證這幾個方向去查。
瀏覽器錯誤代碼透露的排查方向
瀏覽器丟出來的那行英文代碼不是隨機出現的，它已經在暗示問題卡在連線的哪一段。Google Chrome 說明中心的頁面整理了常見的連線錯誤訊息，也提到在網址列輸入chrome://network-errors/可以查到完整的錯誤代碼對照表，先看懂這行字，能少走很多冤枉路。
幾個最常遇到的代碼，各自代表不同的故障位置：
DNS_PROBE_FINISHED_NXDOMAIN：瀏覽器連 DNS 解析都做不到，查不到這個網域對應的 IP 位址，常見原因是網址拼錯字、網域根本沒註冊過、網域已經到期，或是本機端的 DNS 設定、防火牆擋住了查詢。ERR_CONNECTION_TIMED_OUT：DNS 已經解析出 IP 位址，但連上那個位址之後，對方在時限內完全沒有回應，可能是伺服器沒開機、防火牆擋掉了連線，或是網路壅塞。ERR_CONNECTION_REFUSED：對方主動拒絕了這次連線請求，Chrome 說明中心對這個代碼的說明是「網頁拒絕 Chrome 進行連線，或網頁遭到封鎖」。ERR_SSL_PROTOCOL_ERROR：連線其實已經連上對方主機，只是 SSL/TLS 的交握失敗，問題出在憑證或加密協定這一層，跟前面幾種網路本身的問題不一樣。
分清楚眼前這行代碼屬於哪一種，問題卡在 DNS、連線，還是憑證這幾層，就已經先答對一半。
清空瀏覽器與 DNS 快取通常最快見效
如果前面的測試結果是「別人都打得開，只有我打不開」，問題通常出在你自己這台電腦或路由器裡殘留的舊資料。不管是一般訪客還是站長自己在做基本排除，都可以先花兩分鐘做這幾件事，不必急著懷疑對方主機出狀況。
電腦端最常見的原因是 DNS 快取記住了舊的紀錄。Windows 可以在命令提示字元輸入ipconfig /flushdns清空本機的 DNS 快取，讓下一次查詢重新問一次 DNS 伺服器，而不是沿用舊的結果；macOS 與 Linux 也各自有對應的清除指令，系統不同、指令不同，但目的都一樣。
如果覺得問題出在網路服務商（ISP）自己的 DNS 快取記錄了舊資料，也可以把預設的 ISP DNS 換成公用 DNS 服務，例如 Google Public DNS。不過換了公用 DNS 也不代表立刻拿到最新結果，Google Public DNS 的常見問答說明，在記錄的 TTL 到期之前，它自己保留的快取也可能還是舊資料（一般最多保留 6 小時），另外也提供一個線上 Flush Cache 工具，讓使用者手動清除對某個網域保留的快取紀錄。除此之外，順手把 VPN 或代理伺服器關掉再試一次，也開一個無痕視窗測試，排除瀏覽器擴充套件、舊憑證快取這些干擾因素，常常比想像中更快找到答案。
網域忘記續約，網站就會直接從網路上消失
這是最容易被忽略，卻也最常見的「整個網站憑空消失」的原因，不是主機壞掉，也不是程式出錯，單純是網域註冊到期沒有續約。網域過期之後，註冊商會在網域被刪除前中斷它的 DNS 解析，整個網站包括電子郵件信箱都會跟著連不上，而且看起來的症狀跟主機故障幾乎一樣，很容易把排查方向帶錯地方。
網域到期之後不會馬上被收回，還有一段可以搶救的緩衝期，只是拖得愈久，贖回的代價愈高；要確認自己的網域現在走到哪個階段，也有一個不透過任何商業平台、由 ICANN 提供的公開查詢管道。
過期後網域不會立刻消失還有搶救的緩衝期
ICANN 把網域到期後的處理流程分成三個階段，越晚處理，贖回的代價越高：
- 自動續約寬限期（Auto-Renew Grace Period）：ICANN 政策把上限訂在 45 天，但給不給、給幾天都由各註冊商自行決定，有的只給幾天、有的用到 45 天封頂。這段期間內還能把網域續約回來，只是註冊商可能另外收費，天數與費用都要看註冊商的服務條款。
- 贖回寬限期（Redemption Grace Period）：自動續約寬限期結束仍未續約，註冊商會刪除這個網域，進入為期 30 天的這個階段，DNS 解析會被停用、也不能轉移註冊商，網域擁有者仍然可以透過註冊商申請贖回，只是註冊商可能另收一筆贖回費。
- 等待刪除期（Pending Delete）：贖回寬限期結束後，還有大約 5 天的緩衝，之後網域才會真正從登錄機構釋出，任何人都可以重新註冊。
三個階段合計下來，從到期到真正被釋出，最長的情況下整個週期可以來到 80 天上下，但如果註冊商的自動續約寬限期比較短，實際等待的時間會短很多。
ICANN 的公開查詢工具能看到網域真正的到期日
想知道自己的網域現在處於哪個階段，不需要透過任何商業平台或註冊商的客服頁面，ICANN 本身就提供一個公開查詢工具 ICANN Lookup，只要輸入網域名稱，就能直接看到這個網域目前的登記狀態、建立日期、到期日、註冊商，以及名稱伺服器等資料。
這個工具採用 RDAP 協定（Registration Data Access Protocol），由網際網路工程任務組（IETF）這個技術社群制定，用來取代舊有的 WHOIS 協定。ICANN 在查詢工具的說明中也提到，查詢結果是直接由登錄機構或註冊商即時提供，ICANN 本身並不會另外收集或保存這些資料，所以查到的到期日就是登錄機構或註冊商當下的紀錄。
換過主機或改過 DNS 紀錄後全球生效需要時間
如果你剛換了主機商，或是把網域指向新的伺服器，設定改完之後，並不是全世界的訪客會在同一秒看到新的網站，這中間的落差常常被誤會成「設定失敗」，其實只是還沒生效完全。
每一筆 DNS 紀錄都有一個叫做 TTL（Time to Live，存活時間）的欄位，決定全球各地的 DNS 解析伺服器要把這筆紀錄快取多久。Cloudflare 的 DNS 文件說明，TTL 設得愈長，紀錄異動要生效的時間就愈久，因為 TTL 沒有過期之前，使用者查到的可能還是舊的 IP 位址；全球各地的 DNS 解析伺服器各自在不同時間點快取了同一筆紀錄，各自的 TTL 計時器到期時間也不一樣，所以同一次 DNS 異動，有人幾分鐘內就看到新結果，有人可能要等到自己那份快取的 TTL 跑完才會更新，以 Cloudflare 為例，可設定的 TTL 從 30 或 60 秒到 1 天不等。
與其枯等，不如直接檢查兩個地方：A 紀錄或 CNAME 紀錄是不是已經指向新主機的 IP 位址，以及網域的名稱伺服器（NS）是不是已經指向正確的 DNS 服務商。Cloudflare 的文件也提到，經過它代理的紀錄 TTL 固定為 300 秒，各地的解析伺服器不會把這類紀錄快取超過 5 分鐘，所以異動通常很快就會生效；但使用者實際看到變更的時間仍可能更久，因為本機的 DNS 快取不一定會同步更新。
主機資源被用光也會讓網站直接打不開
DNS 與網域都確認正常之後，問題往往就出在主機或伺服器這一端，資源被用光、程式當機，或主機商正在維護，從外部看起來都會是同一種「打不開」的症狀，這是站長要動手查的核心環節。
先分清楚是主機完全沒有回應，還是有回應、只是回應內容變成一頁錯誤訊息，這兩種情況指向的方向不一樣，前者可能是伺服器資源被用光或當機，後者則要看回應的錯誤代碼是哪一種。
502、503、504 錯誤代表故障位置不同
這三個代碼常被籠統當成同一種「網站掛了」，但它們指向的故障位置並不一樣，判斷對了才不會找錯人求助。MDN 文件對 502 Bad Gateway 的定義，是伺服器扮演閘道或代理伺服器的角色時，從上游伺服器收到一個無效或無法使用的回應時送出的錯誤；504 Gateway Timeout 則是閘道或代理伺服器在時限內完全沒有收到上游伺服器的任何回應，跟 502 的差別在於，502 是收到了回應但內容有問題，504 是根本沒等到回應。
503 Service Unavailable 又是另一種情況，代表伺服器本身還在運作，只是暫時沒辦法處理這個請求，常見於伺服器過載或正在維護中。502 與 504 通常代表前面還有一層代理伺服器或 CDN 在轉發請求，503 則多半是原始伺服器自己撐不住；判斷是哪一種代碼，能幫你少猜錯好幾次方向。
主機商維護公告與站長常漏看的線索
很多「網站掛了」的通報，其實主機商早就在後台或狀態頁貼出公告，只是站長沒有第一時間去看。遇到打不開的狀況，與其急著重新安裝程式或改設定，不如先登入主機商後台，看看有沒有系統公告或服務狀態頁，說明目前是不是正在維護、或已知有服務中斷。
順手也檢查一下主機資源的使用量報表，是不是已經觸頂，流量、儲存空間或資料庫連線數用滿，都會讓網站對外看起來像是掛了。另外回想一下最近有沒有更新過主機方案、搬過家，或帳單是不是到期還沒繳費，這幾個都是站長自己容易忽略、卻很常見的原因。
憑證過期或設定錯誤，瀏覽器就直接擋下連線
前面幾種情況都是網站真的連不上，這一種不一樣，網站其實是連得上的，是瀏覽器自己主動擋下這次連線，因為 SSL/TLS 憑證過期、設定錯誤，或憑證不受信任，而不是 DNS 或主機掛掉，排查的方向完全不同。
常見的觸發原因包括憑證已經過期、憑證登記的網域跟實際造訪的網域不符，或是憑證鏈不完整。ERR_SSL_PROTOCOL_ERROR，以及 Chrome 說明中心列出的各種憑證錯誤警告，例如憑證日期無效的NET::ERR_CERT_DATE_INVALID、網域不符的ERR_CERT_COMMON_NAME_INVALID，都屬於連線層已經建立、但憑證或加密協定驗證沒通過的這一類錯誤，跟前面 DNS 或逾時類錯誤的成因完全不一樣，站長看到這種畫面，該查的是憑證的有效期限與安裝方式，不是 DNS 或主機狀態；如果是訪客自己遇到NET::ERR_CERT_DATE_INVALID，Chrome 說明中心也提醒先確認裝置本身的日期與時間有沒有設錯。
防火牆規則太嚴格也可能擋下正常訪客
如果前面幾種原因都排除了，網站其實一切正常，只是安全機制把這位訪客誤判成威脅，擋在外面，這種情況下，訪客與站長各自能做的事不一樣，這也是為什麼「無法連上這個網站」不能只怪 DNS 或主機。
CDN 或 WAF（網站應用防火牆）的安全規則，可能因為訪客的 IP 位址、使用了 VPN、所在國家，或瀏覽器特徵被判定為可疑流量，就直接拒絕連線。Cloudflare 的 WAF 常見問答列出幾種常見的阻擋原因，包括防範惡意流量或 DDoS 攻擊、短時間內送出過多請求而觸發速率限制、看起來像機器人的自動化流量，以及 IP 位址被列在公開的黑名單上。這些都是網站方安全機制主動做出的判斷，不是伺服器故障。
遇到這種畫面，訪客能做的是把錯誤頁面截圖下來，錯誤頁下方通常會有一組 Ray ID，連同發生的時間一起提供給網站方協助排查；網站擁有者則可以到後台的安全性事件記錄裡，用這組 Ray ID 或訪客的 IP 位址去搜尋，找到是哪一條規則觸發了阻擋，再決定要調整規則還是加入白名單。
排查到最後，訪客與站長的下一步並不相同
把前面幾節都查過一輪還是打不開，代表已經超出「自己動手能排除」的範圍。訪客跟站長接下來要做的事完全不一樣，分開來看才不會變成一份誰都用不上的清單。
訪客不必深究原因，改用其他管道聯繫對方
如果只是想找到這個網站背後的商家或機構，不是要負責把它修好，做完前面幾節的基本判斷就夠了，接下來該做的是換一個聯繫管道，而不是繼續深究技術原因。
可以改用這個品牌的社群帳號、電話，或電子郵件聯繫；如果之前曾經瀏覽過這個網站，也可以試試搜尋引擎的頁庫存檔，或網路封存服務，先看到舊版的內容應急，等對方恢復之後再回來查最新資訊。
站長聯繫主機商前先備妥時間戳記和錯誤代碼
站長如果排查到這一步還是沒有頭緒，問題可能出在自己權限管不到的地方，例如機房、上游網路，或註冊商系統這一層，這時候需要找主機商或註冊商的客服協助。
準備好幾樣資訊，能大幅縮短對方排查的時間：故障發生的確切時間，連時區都要講清楚；瀏覽器實際看到的錯誤代碼截圖；故障前後有沒有動過 DNS 設定或主機的相關設定；還有前面用不同網路、不同地區測試過的結果。這些資訊愈具體，對方愈快能定位到問題出在哪一段。
監控機制建立好之後不必再等訪客通報故障
前面幾節列出的原因，幾乎都要等到訪客或客戶打不開網站、回報過來，你才知道出事。與其每次都被動等通報，不如自己先一步發現問題，做法不複雜：定期從外部發送連線測試，同時設定憑證到期提醒與網域到期提醒，三件事同時做到位，才不會有漏網之魚。
監控的範圍要對應前面幾節講過的獨立原因，不能只看主機連線這一項。網域到期日、SSL 憑證到期日，跟主機連線狀態，是三個各自獨立、卻同樣會讓網站「看起來正常卻打不開」的地方，只要有一個沒注意到，前面辛苦排查出來的問題，遲早會用同一個原因再發生一次。
「無法連上這個網站」很少只有一種原因，查對方向比查得快更重要。分清楚是自己這端還是對方那端，再往下一路縮小範圍，比從頭到尾照抄同一套步驟有效得多。等到哪天真的需要跟主機商或註冊商求助，手上多一組時間戳記與錯誤代碼，對方就能直接跳過猜測，少走很多冤枉路。