網站突然404或500，先保存出錯網址與時間，再看對應的日誌。寶塔的響應日誌和錯誤日誌各有用途：前者幫你找請求與回應，後者提供服務執行中的錯誤線索。只翻最近一行，或者只看一個狀態碼，都不一定能定位原因。
以下依寶塔、Nginx、Apache及MDN官方文件整理核對方法，沒有替你的網站產生測試日誌。實際欄位、檔案位置和保留範圍以現場配置為準，先找對站點和時間，再判斷下一步。
先留下足以找到請求的資訊
保存完整網址、HTTP方法、發生時間與畫面中的錯誤。若只有某個內頁出錯，就記錄它的路徑，不要只留域名首頁。表單或API也需要方法資訊，因為同一路徑的GET與POST可能走不同處理。
時間要包括時區，並留意瀏覽器、面板和伺服器記錄可能不同。寶塔官方響應日誌介紹包含帶時區的請求時間；用它對照自己的觀察，避免在另一個小時的紀錄裡尋找錯誤。
如果問題涉及登入或特定資料，記錄必要步驟即可，密碼與私人資訊不要放進公開截圖。診斷需要辨認請求，不需要把使用者的完整資料交給所有求助者。
從正確站點打開網站日誌
寶塔官方步驟是進入網站清單，選中目標站點，再打開網站日誌。頁面分成響應日誌、錯誤日誌與日誌安全分析；先確定你正在查看出錯網站，而不是同一台伺服器上的另一個站點。
響應日誌文件列有客戶端IP、請求時間、方法及資源路徑、狀態碼、內容長度、Referer與User-Agent等資訊。IP歸屬地在官方頁被標為企業版功能，不要把介面缺少它當成一般站點的日誌故障。
不同版本與日誌格式可能影響展示。Nginx的log_format及Apache的LogFormat都可決定記錄欄位，因此不能假設每份日誌都包含相同內容，或用欄位位置直接套用另一台主機的解析方式。
響應日誌先確認請求是否出現
用剛才保存的時間、方法與路徑尋找相應請求。如果找不到，先核對站點、時區、保留範圍、是否啟用日誌，以及請求是否經過代理或另一個入口。沒有在這份日誌看到，不足以證明訪客沒有發出請求。
找到後查看狀態與相關內容。MDN把回應狀態分成資訊、成功、轉址、客戶端錯誤及伺服器錯誤等類別；狀態可以縮小方向，但不代替對錯誤內容及實際功能的核對。
例如200可能是正確頁面，也可能是應用以成功狀態提供的通用錯誤畫面。404則表示資源未找到，但仍要辨認是哪一層回應；不要只看到數字，就直接重裝程式或修改所有路由。
再對照同一時段的錯誤日誌
寶塔錯誤日誌介紹列出發生時間、進程資訊、請求及錯誤詳情等線索。先找同一請求附近的相關紀錄，而不是把最新一條不相干錯誤，直接解釋成眼前問題的原因。
Nginx的error_log具有配置位置與嚴重程度；設定某個等級時，會記錄該等級與更嚴重的訊息。這表示看不到某種較低等級資訊，可能與配置有關，不能直接推斷服務完全沒有異常。
不要為了找一個問題就長期開最高詳細程度。詳細紀錄可能增加負擔並帶出更多資料；先使用現有證據，必要的臨時調整應由維護者安排，並記錄原值與結束條件。
Web服務日誌不等於應用程式日誌
PHP或框架本身可能有自己的日誌位置與錯誤處理。Web服務只看到請求失敗，不一定會保存完整應用例外。應按實際程式的文件和配置核對，不把寶塔網站錯誤頁當成所有錯誤都會出現在同一個檔案的承諾。
反向代理也可能把後端狀態轉交給訪客。這時要分別找代理和後端的相應紀錄，並對照路徑與時間；不能因為公開入口是寶塔網站，就只看前面的那份日誌。
Apache官方日誌指南把存取與錯誤紀錄分開說明。若站點使用Apache，核對它的實際設定；不要把Nginx的指令或假設中的檔案路徑原樣套到另一種服務。
代理後的IP不能只看名稱判斷
經過CDN或代理時，日誌裡的連線來源可能是代理節點，也可能由已配置的來源資訊還原。先核對實際格式與信任設定，不把某個欄位名稱叫客戶端IP，就一律認定它是訪客真實位址。
也不要只靠User-Agent或Referer判定身分。這些請求資料有診斷用途，但不等於可靠登入資訊；來源網頁欄位缺少或出現特殊值時，先看請求整體，不直接把它當成攻擊成功的證據。
若需要交接，用時間、路徑、狀態和相應錯誤組成最小片段，遮去敏感參數。完整日誌可能包含多位訪客與私人網址，公開貼整份往往超出排查需要。
安全分析結果要回到原請求核對
寶塔官方頁說明，日誌安全分析也包含已攔截的請求。因此，看到攻擊類型標記，不表示該請求已成功入侵，更不能只憑掃描摘要就宣稱整個網站安全。
回到原始請求與服務處理結果，區分嘗試、攔截及真正產生的影響。若需要調整告警或定期掃描，另外按站點負載與既有維護安排處理，不把閱讀日誌擴成未經核對的自動規則變更。
保留證據，不用清空日誌驗證修復
修復前保存相關紀錄與原設定，修復後以相同合法請求重新核對功能及新日誌。不要清空所有日誌，只為讓畫面看起來沒有錯誤；歷史證據可能正是辨認重複問題的重要依據。
如果日誌已輪替，查看現場保留的舊檔與時間範圍，不假設目前顯示的檔案包含所有歷史。檔案不在或紀錄超出保留範圍時，清楚寫成證據缺口，不補上沒有讀到的結果。
最後將問題網址、對應響應、相關錯誤、處理內容及重新核對時間保存成一組紀錄。下一位維護者就能看懂你是根據哪些線索處理，而不是只留下「重啟後正常」這種無法還原原因的說法。
評論0