寶塔教程

舊域名轉到新域名，首頁能跳，內頁卻全部回到首頁，先核對重定向的目標與URI保留設定。301與302表示轉址的性質，但它們本身不決定路徑是否保留；狀態碼、目的地和路徑需要分開確認。 以下依寶塔、MDN及Nginx官方文件整理設定思路。網址是示例，不是已替你的站點建立規則；先把需要的映射寫清楚，再到面板處理，避免一條全站轉址把原本有效的內容入口一起導錯。 先寫來源和目標，不先選狀態碼 先列出完整來源網址與預期目的地，包括協定、主機名稱及路徑。例如舊站的/articles/guide若在新站仍有相同路徑，可以考慮保留；若新站已改用另一種路由，就不能只換域名，期待內頁自動存在。 也分清這次是全域名搬遷、某個目錄變更，還是單一頁面換位置。規則範圍越大，越要核對不同網址的結果。不要為了一張頁面改網址，就先建立影響整個域名的規則。 目標必須能正常提供需要的內容。寶塔官方重定向頁也要求有效的目標URL；瀏覽器成功跳到另一個網址，不代表那裡不是404、登入頁或另一張轉址頁。 301永久，302臨時，按變更目的選擇 寶塔介面提供301永久重定向與302臨時重定向。MDN分別說明兩種狀態的語意：301表示資源永久移往Location指定位置；302則表示暫時位於另一個位置。 已確定長期使用新網址時，永久轉址可以表達這個安排。若只是臨時維護或尚未確定的入口，先不要用永久性語意宣告所有內容都已搬走。這不表示任何測試都必須用同一種狀態碼，而是要把預期安排說清楚。 也不要承諾301一定立即完成搜尋結果更新，或302一定不影響任何搜尋表現。HTTP狀態表達的是回應語意；搜尋系統何時重新讀取與處理，是另外的觀察，不能用面板保存成功代替成效。 寶塔的URI保留選項決定內頁去向 在網站清單選中目標站點，打開重定向，再添加規則。依官方文件核對重定向類型、目標URL、方式及保留URI參數。域名規則與路徑規則要符合你剛才列出的範圍。 寶塔官方示例說明，從舊域名轉到新域名，保留URI時，/1.html仍轉到新域名的/1.html；不保留則轉到新域名根目錄。這個差異解釋了為什麼首頁測試正常，內頁卻全部落到首頁。 保留路徑的目標示例： https://old.example.com/1.html → https://new.example.com/1.html 不保留路徑的目標示例： https://old.example.com/1.html → https://new.example.com/ 上面是用來討論預期結果的網址，沒有代表你的面板已生成這條規則。若新站路徑和舊站不同，應安排明確映射，不能只勾保留選項就宣稱內容搬遷完成。 查詢參數也要用真正需要的網址核對 商品篩選、文章頁碼或追蹤網址可能帶查詢參數。先確認哪些參數需要延續，哪些屬於舊系統專用資訊；不要一律刪掉，也不要把可能包含敏感內容的參數原樣送到不相關目的地。 面板選項描述包含子路徑或參數，但具體規則仍需以實際回應核對。挑一條需要參數的合法網址，看Location中的目的地是否符合預期，再查看抵達後的頁面內容。 如果自己編輯Nginx規則，依官方rewrite模組核對return與rewrite的語法和參數處理。不要把某個泛用片段當成寶塔每種版本都會生成的固定配置，更不要直接覆蓋已有業務規則。 看第一次回應和完整跳轉鏈 只看瀏覽器最後的網址，可能看不到中途經過幾次轉址。MDN的Location文件說明它指定重定向位置；核對時記錄第一個狀態碼和Location，再沿著鏈查看下一個回應。 如果來源轉到目標，目標又轉回來源，就可能形成循環。常見的排查方向是域名、HTTP與HTTPS及不同層的既有規則，但不能單憑現象就刪除所有規則。先把每一跳記下來，才能找出互相矛盾的位置。 也看是否有不必要的多跳。來源HTTP先換域名、再升HTTPS、再加www，可能經過多次跳轉；若要調整，先確認每個正式入口的憑證與最終網址，不能只為減少跳數就忽略來源端的HTTPS要求。 表單與API不要當成一般頁面轉址 301與302遇到POST時，瀏覽器可能在後續改用GET。MDN指出，若需要保留方法，308或307具有不同要求。因此，登入、付款或API入口不能因一般GET頁面轉址正常，就直接套用同一判斷。 這不是要求你在寶塔介面選一個它沒有提供的選項，而是提醒先核對業務需要。若涉及方法與請求內容保留，應按應用和服務能力設計相應方案，不把301或302當成所有請求都能透明搬遷的保證。 也不要拿正式付款或寫入資料的請求隨意試驗。先由維護者辨認影響範圍，使用適當的驗證方式核對，讓入口變更和業務資料處理保持可追蹤。 先確認目標內容，再擴大規則 若新站的內容尚未全部就緒，可以先列出已完成與未完成的路徑，再決定哪些入口適合切換。把所有舊網址導向新首頁，雖然可能不再顯示舊站內容，卻會讓原本尋找特定文章的訪客失去對應位置，不能把這種結果稱為逐頁搬遷完成。 驗收時也看頁面內容是否真是該篇文章，而不是新站以成功狀態回傳的通用錯誤頁。HTTP回應和內容映射都需要核對，才知道路徑保留是否達到原本目的。 完成時保存規則與網址樣本 至少保存首頁、一條內頁、一個帶參數的合法網址及必要的例外入口，記錄來源、第一次回應與最終內容。每個樣本都需要符合預期，不能只用首頁跳轉成功作全站結論。 變更前後也保留原規則與時間，讓之後看到舊結果的人知道它是歷史記錄還是新的現場觀察。如果永久轉址已被快取，重新核對時要留意不同客戶端的結果，不要急著反覆改回相反方向。 最後把這次搬遷的範圍寫清楚：哪些網址保留路徑，哪些另有映射，哪些暫時不調整。這份紀錄比只寫「已開301」更有用，下次新增內容或改路由時，也能知道該核對哪些入口。 參考資料寶塔官方：重定向與URI保留MDN：301永久轉址MDN：302臨時轉址MDN：Location回應標頭Nginx：return與rewrite

寶塔面板打不開，網站卻仍能訪問，先分清管理面板端口與網站端口。兩者提供不同入口，改面板端口不等於改所有網站的HTTP與HTTPS，也不能因網站正常就認定面板入口必定正常。 以下依寶塔、MDN及Nginx官方文件整理核對方法。沒有替你的主機改端口或放行規則，示例數字也不是當前面板值。先取得實際入口與可回復的管理方式，再安排任何變更。 先看完整網址，分清端口和路徑 MDN的URL文件把協定、主機、端口與路徑分開。端口位於主機名稱後，以冒號分隔；後面的斜線與內容則屬於路徑。不要把安全入口路徑誤認成端口，也不要只保存IP而遺漏其他部分。 普通HTTP與HTTPS使用標準端口時，網址常省略80與443。面板若使用另一個端口，訪問方式就需要相應資訊。網站域名首頁可以開，和同主機另一個管理端口能否連線，是不同核對項目。 也保留正確協定。HTTP與HTTPS涉及不同服務條件，不能只更換網址前面的字樣，就認定某個端口會自動提供相應加密服務。證書與入口配置仍要按實際環境核對。 從安裝資訊或現場設定找真正的面板端口 寶塔官方修改面板端口頁說明，當前安裝會生成隨機端口，並可從安裝完成的終端提示查看。不要把舊教學中的8888當成每台主機現在的固定值，也不要在不知道入口時盲目開放一整段端口。 若已有面板存取能力，官方步驟是在面板設定的安全設定裡找到面板端口。先記錄目前值和完整管理入口，再決定是否需要修改；不要因文件舉了某個數字就照抄。 舊截圖或維護紀錄也可能過時。若有人曾修改端口，先核對最新保存的現場資訊；把歷史入口填回瀏覽器失敗，不能直接證明面板服務停止。 網站端口由網站服務配置負責 寶塔域名管理文件描述網站域名綁定，預設使用80，也能以域名加端口的格式指定其他端口。這是網站入口，不是管理面板端口設定；在網站欄位添加一個名稱，不會替你更改面板服務。 若網站使用Nginx，官方listen指令設定相應位址與端口。核對網站時應看它的服務配置；核對面板時則找面板入口。不要把這兩組資訊寫在同一欄，讓下一位維護者以為所有服務都共用一個值。 同一主機可以有多個網站與管理服務，實際安排依配置決定。IP相同只是地址線索，還要看協定、端口和服務如何選擇請求，不能只用主機地址作完整驗收。 修改之前，先核對新入口的放行安排 寶塔官方端口文件提醒，有雲安全組時要提前放行新端口，修改頁也要求先確認放行。這不表示可以對所有來源全面開放；應依既有管理需求及網路安排限定必要存取。 雲服務商安全組、主機防火牆及服務監聽是不同條件。某一層允許，不代表其他層也已符合；若新的面板端口連不上，逐層核對，不要只反覆按面板保存。 先保留能回到主機的管理方式，並確認誰有權處理回復。不要在唯一可用的入口內，未準備替代方式就改掉連線條件，讓變更之後無法取得必要現場資訊。 按官方步驟變更，保留前後值 寶塔官方步驟是在面板設定、安全設定的面板端口處輸入新值，確認已了解放通端口，再設定。操作之前核對選中的主機，保存原值、新值及時間，避免多台面板同時維護時改錯目標。 文件提供建議範圍，但不表示其中每個值在你的主機都未被占用或適合使用。先按現場服務安排核對，不要把端口號碼較大，當成一定不會衝突的保證。 本篇沒有替讀者執行這些步驟，也不提供需要隨意貼進正式主機的批次改動命令。若環境有反向代理、面板域名或額外入口策略，應一併核對其影響範圍。 變更後分別核對面板和網站 使用新完整入口確認能取得預期面板，而不是其他服務的頁面。若有安全入口或登入限制，也按既有安排核對；只收到某個HTTP回應，不能直接代表管理存取已恢復。 同時以正式網站網址確認原有HTTP與HTTPS仍提供需要的內容。這不是預設改面板端口會影響網站，而是把兩組服務各自驗收，讓紀錄清楚反映本次變更範圍。 網站可以開而面板不能開時，先查面板新值、服務入口與網路條件；面板可以登入而網站異常時，則回到網站配置。不要把其中一個結果擴稱成整台主機所有服務都正常。 失去面板入口時，使用已保留的回復方式 寶塔官方修改頁說明，若改端口後無法訪問，可在SSH命令列透過bt命令改回原端口。實際操作仍需相應主機權限與現場核對，不能把這句說明當成每台主機都已具備可用SSH的證據。 回復後再確認面板入口與原網路規則，保留此次失敗原因。不要在失去資訊時連續猜改多個端口，或為了快速開啟面板就停用所有防火牆限制。 若沒有可用管理入口，先由有權處理主機的人安排恢復，而不是對正式服務作無目的重啟。需要知道服務實際狀態，才能判斷是端口資訊錯誤、網路限制還是其他故障。 換端口只是入口安排的一部分 更換面板端口不能代替密碼、存取來源限制、更新與其他管理措施，也不保證網站安全。它改變的是入口位置，不能讓不合適的權限或公開管理服務自動變成安全安排。 最後保存非敏感的主機對應、端口用途、變更前後值及核對時間，管理入口等資料則依既有方式保護。讓面板和網站各有清楚紀錄，下次故障就能直接找到該查的服務。 參考資料寶塔官方：面板端口寶塔官方：修改面板端口寶塔官方：網站域名與端口MDN：URL端口與路徑Nginx：listen服務入口

網站突然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判定身分。這些請求資料有診斷用途，但不等於可靠登入資訊；來源網頁欄位缺少或出現特殊值時，先看請求整體，不直接把它當成攻擊成功的證據。 若需要交接，用時間、路徑、狀態和相應錯誤組成最小片段，遮去敏感參數。完整日誌可能包含多位訪客與私人網址，公開貼整份往往超出排查需要。 安全分析結果要回到原請求核對 寶塔官方頁說明，日誌安全分析也包含已攔截的請求。因此，看到攻擊類型標記，不表示該請求已成功入侵，更不能只憑掃描摘要就宣稱整個網站安全。 回到原始請求與服務處理結果，區分嘗試、攔截及真正產生的影響。若需要調整告警或定期掃描，另外按站點負載與既有維護安排處理，不把閱讀日誌擴成未經核對的自動規則變更。 保留證據，不用清空日誌驗證修復 修復前保存相關紀錄與原設定，修復後以相同合法請求重新核對功能及新日誌。不要清空所有日誌，只為讓畫面看起來沒有錯誤；歷史證據可能正是辨認重複問題的重要依據。 如果日誌已輪替，查看現場保留的舊檔與時間範圍，不假設目前顯示的檔案包含所有歷史。檔案不在或紀錄超出保留範圍時，清楚寫成證據缺口，不補上沒有讀到的結果。 最後將問題網址、對應響應、相關錯誤、處理內容及重新核對時間保存成一組紀錄。下一位維護者就能看懂你是根據哪些線索處理，而不是只留下「重啟後正常」這種無法還原原因的說法。 參考資料寶塔官方：網站日誌Nginx：存取日誌格式Nginx：error_logApache：日誌指南MDN：HTTP狀態碼

把Laravel專案上傳到寶塔，網站卻顯示目錄、404，甚至把不該公開的檔案送給訪客，先核對「專案放在哪裡」和「網站從哪裡提供檔案」。兩者可以是不同目錄。框架把公開入口放在public時，不能只因整包程式已上傳，就讓網站直接指向專案根目錄。 以下依寶塔、Laravel、Nginx及PHP官方文件整理設定方法。目錄樹是說明用示例，請換成自己的實際路徑；不同專案的入口結構不同，不能看到public這個名稱，就替所有網站套用同一設定。 先找入口，不先猜目錄名稱 先看專案的部署文件，確認哪個目錄包含對外入口。以Laravel為例，官方部署文件要求Web伺服器把請求導向public/index.php，並明確提醒不要把index.php移到專案根目錄，否則可能暴露敏感設定。 my-project/ app/ bootstrap/ storage/ vendor/ .env public/ index.php images/ 這個示例中，my-project是完整程式所在目錄，public才是網站公開入口。app、vendor與.env不應因為上傳到同一專案，就成為瀏覽器可以直接取得的網站檔案。不要用「先把網站開起來再說」為理由，將所有內容放進公開入口。 如果是純HTML網站，入口可能就在上傳目錄；如果是其他框架，則以它的部署文件為準。也確認目前資料夾不是壓縮包解開後多套一層的結果，例如你以為指向專案，實際卻指向只包含另一個專案目錄的外層。 寶塔的網站目錄與運行目錄分開核對 寶塔官方網站目錄說明，把網站目前部署目錄與運行目錄分開列出。運行目錄用來指定二級目錄，文件以ThinkPHP5與Laravel這類程式為例。這不是要求把完整專案搬進public，而是讓Web入口落在正確的位置。 在網站清單選中正確站點，查看它的網站目錄，再核對運行目錄。先記下變更前的完整路徑，避免同一台伺服器有多個相似站點時，把另一個網站的目錄改掉。若清單顯示的路徑和你上傳的位置不同，先處理這個差異。 假設專案放在/www/wwwroot/example.com，且公開入口確實是它下面的public，核對結果應讓網站從該public提供內容。介面中的相對目錄和最後生效的完整路徑要一起看，不要只憑下拉選單裡有public就判定完成。 使用Nginx時，查看最後生效的root Nginx官方root指令說明，檔案路徑一般由root所設目錄與請求URI組合。這表示相同的網址，在不同root下會查找不同檔案。若你讀到的是另一份server配置，或者相關location另有設定，單看一個目錄值仍不足以確認所有請求。 Laravel官方的Nginx部署示例把root指向專案的public，並配合請求轉交入口程式的規則。只改root而漏掉框架路由規則，可能使首頁能開，內頁仍404。應依實際Web服務和框架版本核對整套部署要求，不從網上隨便貼一段配置覆蓋現有站點。 這篇用Nginx說明檔案入口原理；若站點使用Apache或其他服務，請核對相應的文件根目錄與路由配置。不要把Nginx指令貼到另一種服務，或把寶塔欄位的顯示值當成所有服務都採用相同配置的證據。 看到404，先區分靜態檔案與框架路由 先挑一個你確認存在的公開靜態檔案，例如public/images內的測試圖片，再看它的網址是否符合公開目錄結構。當public已是文件根目錄，網址通常不再額外帶一層public；不要把磁碟上的完整路徑原樣接到域名後面。 如果靜態檔案也404，優先核對選中的站點、公開目錄、檔名大小寫及檔案是否真正存在。如果靜態檔案正常，但框架內頁404，再查請求如何交給入口程式。這個順序可以避免一看到404，就反覆更改運行目錄。 也不要只檢查首頁。首頁可能由現存HTML檔案提供，並沒有經過你打算使用的PHP入口。應分別核對首頁、已知靜態資源與一條合法的框架路由，記下各自結果，再決定下一個要處理的設定。 防跨站設定不代替公開入口 寶塔網站目錄頁也提供防跨站攻擊設定，涉及PHP的open_basedir。PHP官方文件將它描述為限制PHP可存取檔案的位置，並提醒這只是額外安全措施，不能作為完整安全保證。 因此，即使啟用防跨站，也不能把專案根目錄當作公開目錄，期待它替Web伺服器擋住所有敏感檔案。瀏覽器取得靜態檔案和PHP程式讀取檔案，是不同的行為；公開入口仍需依框架要求設定。 若改入口後PHP報出路徑限制錯誤，核對錯誤涉及哪個檔案和允許範圍，再按專案需要處理。不要為了消除一行錯誤就關閉所有限制，更不要把其他網站的目錄加入，讓本來分開的站點互相讀取資料。 搬站時重新核對路徑，不沿用舊機器的字串 從另一台主機搬過來時，舊配置中的絕對路徑不一定適用新站點。先確認新機器上的專案位置，再核對公開入口和相關程式路徑；不能因域名相同，就認為磁碟目錄、PHP環境與檔案權限也完全相同。 若目前站點已有正常服務，先記錄配置及可還原的版本，再安排範圍明確的變更。更改運行目錄後，使用剛才列出的靜態資源與合法路由重新檢查；出現異常時保留錯誤，不要連續嘗試多個猜測路徑，讓原本可用的設定也失去追蹤。 目錄正確後，再處理執行條件 正確的public入口不代表整個部署已完成。Laravel仍有PHP版本、擴充功能、依賴、環境設定與可寫目錄等要求。官方文件特別列出storage與bootstrap/cache的寫入權限；這些是程式執行條件，不應以公開整個專案來迴避。 遇到500時，保留發生時間、網址與相應錯誤日誌，先判斷是入口配置、PHP執行，還是程式本身的問題。不要在無法辨認原因時同時改目錄、版本與權限，否則即使恢復，也很難知道是哪個變更起作用。 最後保存專案完整路徑、公開入口、Web服務類型與核對結果。下次更新專案時，完整程式仍按原結構部署，對外目錄保持明確；維護者就不會把「程式放置位置」誤當成「所有檔案都可公開的位置」。 參考資料寶塔官方：網站目錄與運行目錄Laravel：部署與public入口Nginx：root指令PHP：open_basedir與核心設定寶塔官方：新增PHP網站

寶塔備份清單顯示成功，先核對這次選了哪些資料、生成哪些檔案，以及下載後能否按預期還原。網站文件和資料庫是兩組不同內容；只取得網站目錄的壓縮包，不代表文章、訂單或帳號等資料也已包含。 以下依寶塔備份與MySQL官方文件整理檢查方法，重點放在備份產物及驗收範圍。這不是本篇已替你的網站做過備份或還原的報告，也不把一個成功狀態當成完整災難復原能力的證明。 先列出網站需要恢復的內容 把網站程式、上傳檔案、資料庫及必要設定分開列出。程式目錄可能包含圖片和設定，但資料庫通常由另外的服務管理；不要因為網站文件都在同一個寶塔站點，就推斷備份其中一項會自動包括全部。 寶塔官方建立備份頁明確分列網站資料、資料庫、應用與配置等可選項。建立之前看清楚勾選範圍，並保存當次選擇與時間；名稱叫「完整備份」，也仍需要實際內容支持。 如果網站使用外部資料庫或另一個物件儲存服務，核對它們是否在這次範圍內。不要把面板列出的本機資料庫，直接當成程式真正連線的資料來源；先查網站使用哪組服務，再安排對應備份。 按官方入口建立可辨認的備份 寶塔官方步驟從備份還原進入建立備份，設定名稱、儲存位置及執行時間，再選擇資料類型。使用有意義的名稱，讓你之後能辨認它屬於哪個網站、哪次變更及哪個時間點。 頁面會顯示預計需要的空間與剩餘磁碟空間。先核對能否完成這次備份，而不是等到磁碟用盡才發現產物不完整。備份工作本身也可能影響站點負載，應按既有維護安排處理。 本地與遠端儲存也要分開記錄。只留在同一台主機，主機故障時可能同時失去網站和備份；但選了遠端選項，也還要核對傳送結果及真正可取得的檔案，不能只看配置名稱。 清單成功之後，逐項核對產物 寶塔備份管理文件列出狀態、備份文件、大小與時間等資訊。確認對應紀錄完成，再核對實際生成的文件；不要只截一張成功標記，卻沒有保存可用產物。 下載後查看檔案是否取得完整，並記錄名稱、大小、時間與雜湊等辨認資訊。雜湊可以用來比較同一份檔案的位元組是否一致，但它本身不證明備份選對資料，也不證明資料在業務上可用。 打開網站文件的備份，核對必要目錄與上傳內容是否在裡面；再找資料庫備份，確認不是只看到網站目錄就停止。若產物格式需要專用還原工具，按該格式的文件處理，不任意改副檔名。 資料庫備份要辨認格式與內容 MySQL官方將實體與邏輯備份分開。實體備份涉及資料庫存放資料的文件；邏輯備份則保存結構和內容的邏輯表示。它們的建立與恢復方式不同，不能把普通網站檔案壓縮包當成任一種資料庫備份。 mysqldump是MySQL官方的邏輯備份工具，但不要因為檔名是.sql，就宣稱它一定由這個工具完整匯出。查看實際產物、生成方式及選項，確認你取得的內容與恢復方案相符。 也核對範圍是否包含需要的表結構、資料及其他物件。不同匯出選項和權限可能影響內容；不把一般資料表備份自動擴稱為所有使用者、權限、事件或伺服器配置都已保留。 網站文件與資料時間要一起考慮 網站持續接收上傳或寫入訂單時，文件和資料庫可能在不同時間取得。若資料庫記錄指向尚未備份的圖片，或文件中含有資料庫尚未保存的內容，還原後可能不一致。 因此，要按實際應用安排一致性策略。MySQL官方備份類型文件說明，運行中的備份仍需考慮資料修改與完整性；不能用「不用停機」直接推論任意複製都能得到一致資料。 記錄備份時間與當時使用的方案，不宣稱面板中兩個成功標記必定代表同一時間點。需要嚴格一致性的網站，應由維護者按資料庫引擎、工具及業務需求設計，不以通用教學替代。 先在合適環境核對還原，不覆蓋正式資料試運氣 寶塔備份管理文件提醒，還原會覆蓋現有資料，並要求先確認檔案完整可用。若要驗證恢復能力，應先安排獨立的目標環境與範圍，不拿正式網站當作隨意試驗的位置。 MySQL的SQL格式還原文件也區分匯出是否帶有建立及選擇資料庫的內容。目標資料庫、帳號與檔案範圍都需要核對，不能把一條網上命令直接貼進現有正式資料庫。 還原後檢查程式能否啟動、必要資料表與內容是否存在、上傳檔案能否讀取，以及關鍵功能是否符合預期。只看匯入工具沒有報錯，仍不足以代表網站已恢復到需要的狀態。 恢復結果和備份狀態分開保存 維護紀錄可分成建立成功、檔案取得、內容範圍核對及恢復驗證。每一項附上當次證據，沒有做過的部分就保留待確認，不把前面的成功自動擴成後面的通過。 若恢復時發現缺少圖片或資料，回到原備份選擇和時間定位問題；不要直接刪掉失敗紀錄，再建立一個同名產物，讓維護者失去比較依據。保留可追蹤的版本與失敗原因，才有機會改善方案。 最後才安排保存與刪除策略 保留期限應按網站資料變更與恢復需求安排，而不是只為節省空間留下唯一一份。刪除之前確認還有哪些可用版本，以及它們是否已取得到需要的位置，不因看到較新的檔名就直接清掉全部舊檔。 備份也可能含有密碼、使用者資料與私人文件，下載與保存位置需要相應保護。不要把備份放回網站公開目錄作為方便下載的捷徑，讓原本不公開的資料變成可直接取得的檔案。 最後把選擇範圍、產物清單、保存位置及恢復核對記錄放在一起。下次需要回復時，就能知道手上資料涵蓋什麼，而不是只有「寶塔曾顯示成功」這一句話。 參考資料寶塔官方：建立備份寶塔官方：備份管理與還原MySQL：備份類型與一致性MySQL：mysqldumpMySQL：SQL格式備份還原

在寶塔把網站切到新的PHP版本，終端執行php -v卻仍顯示舊版本，不一定是切換失敗。網站請求與命令列可以使用不同PHP入口；先分開核對兩者，才不會為了一個命令輸出，改動原本正常的網站環境。 以下依寶塔和PHP官方文件說明檢查順序。文中的命令與短程式是供你核對現場的示例，沒有預設你的安裝路徑、版本或輸出。先記錄網站與命令列各自的入口，再決定是否需要調整。 寶塔站點切換的是該網站的PHP環境 寶塔官方PHP頁說明，可以修改當前站點指定的PHP運行版本，適合已安裝多個版本的環境，也支援自訂PHP連線配置與純靜態站點。它描述的是選定網站的服務設定，不是所有終端命令都一起切換的承諾。 先確認你選中的是需要修改的站點，而不是同一台伺服器上的另一個域名。記下原版本與目標版本，並查程式的版本要求；不要只因新版本可選，就讓舊程式直接承擔相容性變更。 如果網站設為純靜態，就不應把靜態HTML成功打開當成PHP已執行。核對網站真正使用的入口與請求類型，確認你測的是PHP程式，而不是由Web伺服器直接提供的檔案。 php -v回答的是這次命令呼叫的程式 PHP官方命令列文件將CLI與其他SAPI分開，並說明可用php -v查看呼叫的PHP資訊。這個結果對命令列有用，但它沒有替瀏覽器請求讀取寶塔目標站點的設定。 php -v php --ini 這兩個命令分別核對目前呼叫的PHP及配置資訊。不要把示例命令下面想像出的版本當成結果；保存你自己的完整輸出和執行時間，並確認當時使用哪個終端、帳號與工作環境。 若有多個PHP可執行檔，應依現場安裝資料找出正確路徑，再用明確路徑核對。不要直接複製別人的寶塔版本目錄，也不要先修改全域連結，讓同一台機器上的其他命令或任務一起受影響。 比較Web與CLI時，先看版本和SAPI PHP提供PHP_VERSION與php_sapi_name()等資訊，讓你辨認目前程式由哪個環境執行。需要比較兩個入口時，可以在受控、短暫的診斷方式中記錄版本與SAPI；不要把完整環境報告長期放在公開網站。 <?php echo PHP_VERSION, "\n"; echo php_sapi_name(), "\n"; CLI與網站入口得到不同SAPI是合理現象，不能只因字串不同就認定故障。重點是它們的版本、配置與擴充功能，是否各自符合負責的工作。短程式也只讀當次執行環境，不替所有站點提供統一結論。 若你必須透過網站診斷，限制存取範圍，核對完成立即移除。完整phpinfo會展示大量配置及環境資訊，官方文件描述其輸出範圍；排查單一版本差異時，不需要把整份內容公開給所有訪客。 版本相同，也可能讀取不同配置 PHP官方配置文件說明，配置檔的查找位置與執行方式等條件有關，並可能有SAPI專用設定。這解釋了為什麼兩邊版本相同，記憶體限制、擴充功能或其他行為仍可能不同。 核對各自真正載入的配置檔及額外掃描資訊，而不是只找到磁碟上某個php.ini，就認定網站與CLI都在用它。配置檔存在，和這次執行載入它，是兩項不同事實。 如果只在CLI出現缺少擴充功能的錯誤，先查CLI配置；如果只在網站出現，則查站點PHP服務。不要把一邊的錯誤當成另一邊也需要相同修改，或者將所有版本的配置互相覆蓋。 網站能開，不代表命令列任務也相容 網站之外，部署命令、排程與背景工作可能另外呼叫PHP。它們使用的入口應獨立記錄。網站切換版本後，如果某個任務出錯，先核對那個任務實際執行的程式，不要立即把網站切回去。 同樣，手動終端命令成功也不代表排程必定使用相同環境。任務可能記錄明確路徑，也可能依它自己的環境尋找命令。檢查任務設定和執行紀錄，才知道它與剛才的手動測試是否可比較。 若需要統一版本，先列出網站、部署及任務各自的入口，確認相容要求，再安排範圍明確的變更。不要把全域PHP切換當成方便的捷徑，卻沒有盤點其他網站與既有任務。 錯誤訊息要和入口一起保存 看到缺少函式、擴充功能或版本不符時，保存完整錯誤、執行方式及相關PHP資訊。只貼一句「PHP不對」會讓維護者不知道問題來自瀏覽器、CLI還是排程，容易在錯誤的位置調整設定。 也把成功的對照結果記下來。例如網站請求成功而CLI失敗，代表你已有兩個不同入口可比較；先查它們的差異，比同時重裝所有PHP版本更能縮小問題範圍。 若診斷涉及密碼、環境變數或路徑，交接時只提供必要資訊，敏感內容另按既有方式保護。版本和配置核對不需要公開整份網站設定，更不需要把連線密碼放進文章留言或錯誤截圖。 一次只改能說清楚影響的入口 假如問題只出現在某個部署命令，就先讓那個命令使用符合程式要求的PHP入口，並核對結果。這不等於一定要修改整台主機的預設命令，也不等於所有網站都必須立即換版本。把處理範圍寫清楚，才能安排合理的回復方式。 需要修改配置時，同樣保存原值和實際載入位置，再依服務與設定的要求處理生效方式。不要因為編輯了某個檔案，就直接宣稱網站已讀取新值；以對應入口重新核對，並保存當時觀察，才知道變更是否到達需要的環境。 完成後保留一份入口清單 把目標網站PHP版本、CLI可執行檔路徑、各自載入的配置，以及重要任務的PHP入口放在同一份維護紀錄。之後再切換版本，就能逐項核對，不會只看一張面板截圖推斷所有工作都已更新。 最後用真正需要的網站請求與任務功能驗收，而不是只看版本號。版本符合只是執行條件之一；程式依賴、配置與實際功能也需要核對，才知道這次調整是否完成了原本要解決的問題。 參考資料寶塔官方：站點PHP設定PHP：命令列使用PHP：配置檔PHP：php_sapi_namePHP：phpinfo輸出範圍

在寶塔啟用SSL後，瀏覽器仍出現憑證警告，先核對網址中的域名和實際收到的憑證。面板顯示有一張憑證，不代表訪客正在使用同一張，也不代表這張憑證涵蓋所有需要的主機名稱。 以下依寶塔、Let’s Encrypt、Nginx及MDN官方文件整理檢查順序。憑證申請、部署和訪客連線是不同步驟；先分清錯誤發生在哪一步，不用反覆重新申請取代診斷，也不把HTTPS當成整個網站安全或搜尋排名的保證。 把每個正式域名列清楚 先列出example.com、www.example.com及真正需要的子域名。它們看起來屬於同一網站，卻不代表某張憑證一定同時涵蓋。查看憑證的名稱範圍，並和瀏覽器網址逐一比較，不只看面板裡的證書名稱。 Nginx官方HTTPS文件說明，一張憑證可以具有多個名稱，也可以使用泛域名；泛域名的匹配仍有範圍。像*.example.org並不等於同時涵蓋example.org或更深一層的www.sub.example.org。不能只看見星號，就把所有相關網址都視為已涵蓋。 若要讓www轉到根域名，也先核對來源網址的HTTPS。瀏覽器必須先建立來源端的TLS連線，才能收到後續HTTP轉址；不能用「最後會轉走」為理由，忽略來源名稱的憑證問題。 在寶塔選對站點，再查看SSL資料 寶塔官方部署步驟是從網站清單選擇目標站點，打開SSL頁面。使用既有憑證時，把對應私鑰與PEM憑證內容填入相應欄位，再保存並啟用。先確認站點及憑證來源，不要把另一個域名的資料貼進去。 私鑰與憑證需要相互對應，不能因為兩個檔名相似就任意配對。私鑰也不應貼到公開求助內容或文章留言；Nginx官方文件明確區分公開憑證與需要限制存取的私鑰。 面板中的證書資料可用來核對部署設定，但仍要透過正式域名檢查訪客實際收到的內容。若前面有代理或CDN，訪客連線和代理到源站的連線可能涉及不同憑證，先把兩段入口分開記錄。 名稱正確，仍要檢查有效期與憑證鏈 核對目前收到的憑證是否在有效期內，以及完整鏈能否由客戶端信任。Nginx官方文件說明，中間憑證不足可能讓不同瀏覽器表現不同；某台常用電腦能打開，不能替所有客戶端證明伺服器已提供完整鏈。 如果需要串接憑證檔，依簽發機構及Web服務的格式要求處理。Nginx文件要求伺服器憑證在鏈結憑證之前，錯誤順序可能造成服務載入失敗。不要把網上另一個服務的檔案拼接方式直接套過來。 變更之前保存可回復的既有資料與配置。不要在不清楚配對和格式時反覆覆蓋私鑰，也不要只因面板能保存欄位，就認定Web服務已成功使用新憑證。 申請失敗時，先看所選驗證方式 Let’s Encrypt官方說明，簽發前會驗證你控制申請的名稱。HTTP-01透過指定驗證路徑取得內容，使用80端口；DNS-01則要求在相應名稱下提供TXT紀錄。這兩種方式的排查入口不同。 使用HTTP-01時，先核對申請名稱、DNS指向與驗證路徑是否能抵達正確服務。代理、多台伺服器或轉址可能改變請求的去向，不能只因普通首頁能開，就保證驗證內容也能在所有需要的入口取得。 也不要把「有轉址就一定失敗」當成Let’s Encrypt的通用規則。它的官方文件列有可接受轉址條件；應依實際驗證方法及客戶端行為核對。寶塔特定介面或證書品牌的提示，不能直接擴成所有簽發服務的限制。 使用DNS-01時，核對指定TXT名稱與值，並確認查詢時已能取得正確紀錄。DNS更新有傳播與查詢差異，不用重複添加不同值來碰運氣。若要自動更新，也應按既有權限安排必要的DNS憑證，不把完整帳號權限隨意留在網站伺服器。 連線失敗與憑證警告分開處理 如果根本無法連到HTTPS入口，先查服務是否提供預期連線，以及443或你實際使用端口的既有網路規則。寶塔SSL頁也提醒核對安全組。這和已經收到憑證、但名稱不符或不受信任，是不同現象。 能連線卻收到另一個站點的憑證，則檢查TLS站點選擇與部署入口。Nginx文件說明SNI可在TLS握手時傳遞請求名稱；直接測IP和使用正式域名，不能一律當成相同測試。 保留瀏覽器顯示的具體原因、完整網址及發生時間。只說「SSL壞了」會把連線、名稱、有效期和信任鏈混在一起，讓下一位維護者無法知道該查哪一段。 先驗HTTPS，再安排強制轉址 寶塔官方部署頁提供強制HTTPS選項。啟用前，先確認真正需要的HTTPS網址能正常提供網站，再核對既有轉址，避免多個地方互相導向，讓訪客陷入循環。 HTTPS也不會自動修正頁面裡的HTTP資源。MDN說明TLS提供傳輸保護；網站引用的資源、程式權限及其他安全條件仍需另外檢查。不要用一個鎖頭圖示替整個網站的安全性作結論。 更新憑證後，分別核對需要的主機名稱、代理入口和源站，再保存當次讀到的名稱及有效期。這樣下一次出現警告，才知道它是舊憑證仍在服務，還是另一個入口尚未更新。 多入口網站要逐一留下核對結果 可以把根域名、www及其他正式子域名分別記錄，列出訪客連到哪個服務、收到哪些憑證名稱，以及有效期是否符合預期。不要只保存一張面板畫面；如果日後代理和源站更新時間不同，這份入口紀錄能幫你定位仍使用舊資料的位置。 續簽要看實際結果，不只看開關 自動續簽需要驗證條件持續成立。搬站、改DNS、改代理或驗證路徑後，原本的安排可能需要重新核對；不能因為先前開過自動續簽，就等到過期才確認是否成功。 保存續簽紀錄，並確認服務實際提供的新有效期。提醒通知與排程紀錄是輔助資訊，訪客取得的新憑證才是部署核對的一部分；本篇提供官方文件查法，沒有替你的網站宣稱已申請、續簽或部署成功。 參考資料寶塔官方：SSL設定寶塔官方：部署SSL憑證Let’s Encrypt：驗證方式Nginx：HTTPS與憑證鏈MDN：TLS傳輸保護

寶塔反向代理的首頁能開，內頁卻404，先查後端實際收到的路徑。代理不是只把IP換成域名；公開網址的前綴、後端路由、請求Host和靜態資源地址都可能影響結果。 以下依寶塔及Nginx官方文件整理診斷方法。配置片段只解釋Nginx一般原理，不是宣稱某個寶塔版本一定生成相同內容，也沒有替你的網站執行修改。先把預期映射寫清楚，再核對現場。 先列出公開路徑與後端路徑 假設訪客使用/api/users，後端究竟需要/users，還是/api/users？先從後端路由與部署文件確認，不能只因首頁回應成功，就推斷所有內頁都能接受同樣的前綴。 也確認代理的是整個網站，還是其中一個目錄。若只代理/api/，其他路徑可能仍由原站點處理；它們各自的404不能直接合併為同一個代理錯誤。記錄一條已知有效的後端路由，作為核對基準。 寶塔官方反向代理頁要求目標URL可以正常訪問，並提供代理目錄與發送域名等欄位。代理目錄涉及高級功能，介面能力以你的版本為準，不要在欄位不存在時用另一個近似選項代替。 Nginx的proxy_pass有沒有URI，含義不同 Nginx官方proxy_pass說明，帶URI時，匹配location的那部分標準化請求URI會被指定URI替換；不帶URI時，通常按文件所列條件傳遞原始或完整變更後的請求URI。簡單前綴範例可以先看以下差異。 location /api/ { proxy_pass http://127.0.0.1:3000/; } location /api/ { proxy_pass http://127.0.0.1:3000; } 第一段的目標包含/這個URI，對/api/users的簡單映射會移除匹配的/api/，交給後端/users。第二段目標沒有URI，在未另外改寫的普通請求中保留/api/users。兩段是互相對照的替代範例，不要同時貼進同一份配置。 這個差異不是「永遠要加斜線」的口訣。選哪一種取決於後端需要的路徑；正則location、命名location、rewrite及變數又有文件列出的特殊條件。遇到它們時按完整配置核對，不能只盯著最後一個字元。 回到寶塔核對真正生成的配置 面板欄位保存成功，只能先證明設定已被接受，還要查看實際站點配置和回應。不同版本或服務可能有不同生成方式，不能把上面的Nginx例子冒成寶塔UI一定產生的結果。 若要檢查Nginx，先找到目標站點及匹配的location，再看proxy_pass與相關改寫。Nginx核心文件說明location選擇有匹配規則，另一段更具體或正則配置可能接手請求；不是所有/api/網址都一定由你剛看到的那段處理。 變更前保存原配置，避免直接覆蓋其他站點或原有規則。若服務不是Nginx，改查對應服務的代理文件，不將Nginx指令貼到不同配置格式中。 404是誰回的，要靠紀錄核對 MDN將404定義為伺服器找不到請求資源；狀態本身沒有告訴你是哪一層回應。它可能來自前面的Web服務，也可能是後端收到不正確路徑後回傳，再由代理轉交。 保存完整網址、時間和回應，再核對相應的代理與後端日誌。前端日誌記錄的公開URI與後端記錄的路由如果不同，正是定位前綴變換的線索；不要只因錯誤頁有某個服務名稱，就斷言整個問題的來源。 Nginx日誌文件說明，可以按配置使用相應格式記錄請求。實際欄位取決於log_format與相關設定，不能假設每台機器都已記錄上游狀態。若沒有該欄位，先查現有證據，不替日誌補出想像的值。 發送域名影響後端選中的站點 寶塔官方頁把發送域名描述為傳遞到代理請求頭的域名，預設使用目標URL域名，並提醒設定不當可能導致代理不能正常運行。若後端依Host選站點，路徑正確也仍可能收到另一個虛擬站點的回應。 先確認後端需要的Host，再查看實際代理設定。不要因為公開域名和後端域名不同，就一律把某個值改成公開域名；後端可能正是依內部名稱安排服務。 若你自己使用proxy_set_header，依Nginx官方說明核對其作用與變數。請求頭設定和URI改寫是不同工作，改其中一項不代表另一項已符合後端需求。 首頁成功後，也要查靜態資源網址 應用部署在子路徑時，HTML中的絕對資源地址可能仍指向根目錄。例如頁面在/app/，資源卻要求/assets/；該請求可能根本沒有進入/app/代理。先看瀏覽器真正要求的資源網址，再查相應路徑。 這類問題可能需要應用的公開基底路徑設定，而不是再加一個泛用替換規則。寶塔內容替換僅在Nginx提供，官方頁列有條數限制；不要把文字替換當成可靠修復所有腳本、API與資源地址的辦法。 如果是WebSocket或其他特殊協定，也另外依服務能力核對。本篇聚焦普通HTTP路徑診斷，不用一張首頁成功的畫面，替所有連線模式作驗收。 代理後重新核對原有存取限制 寶塔官方頁明確提醒，設定反向代理後，訪問限制中相應路徑的規則會失效。因此，不能只確認頁面能開，就認定原本的存取控制仍在相同位置生效。 先列出原本需要保護的管理、私人內容與寫入入口，再確認目前由哪一層負責限制。不要為了消除404就放開所有路徑，也不要把後端只綁本機，直接推斷公開代理入口必定安全。 後端位址以代理服務的環境為準 目標URL若使用127.0.0.1，它指向代理服務所在環境的本機，不一定是你操作瀏覽器的電腦。容器、另一台主機或不同網路安排，都要按實際部署核對；不要把某個教學的本機端口原樣填入，卻沒有確認那裡存在需要的服務。 連線失敗時先核對目標入口可達性，收到404時再查路徑和後端路由。兩種現象分開記錄，能避免為了處理網路問題反覆改URI，或為了處理錯誤路由去更換正常的端口。 用路徑樣本收束變更 保存首頁、合法內頁、靜態資源、需要參數的路徑與必要例外的核對結果，對照公開URI和後端路由。出現錯誤時按匹配、URI、Host與應用資源地址逐項查，不同時猜改所有設定。 最後把原配置、預期映射及驗收時間放在維護紀錄。下次更新後端路由，就能直接檢查代理前綴是否仍合適，不必重新用「加斜線或刪斜線」碰運氣。 參考資料寶塔官方：反向代理Nginx：proxy_pass與代理請求頭Nginx：location匹配MDN：404回應Nginx：請求日誌

網站已上傳新的index.php，打開域名卻仍看到舊HTML頁面，先查預設文件，不急著刪除整個網站。瀏覽器要求的是目錄網址，Web伺服器還要決定該目錄的入口檔案；目錄裡同時有多個首頁候選，最後顯示哪個，取決於實際服務配置。 以下依寶塔及Web伺服器官方文件整理查法。文中的檔名與配置是說明用示例，不是本站替你的伺服器測得的結果。先辨認網站使用Nginx還是Apache，再看對應的生效設定，避免把不同服務的語法混在一起。 先比較目錄網址與明確檔名 先記下完整網址。https://example.com/和https://example.com/index.php不是同一個請求路徑；前者要求根目錄入口，後者直接指定檔案。若兩者看到不同內容，這是檢查預設文件的線索，不是單憑畫面就能確認的唯一原因。 在正確的公開目錄查看index.php、index.html與其他入口是否同時存在。也核對檔案大小寫和內容，避免把另一個資料夾的舊檔誤認成網站正在使用的檔案。不要先刪檔再查，否則原本的選擇順序和回復依據都可能消失。 如果PHP入口本身報錯，而靜態HTML可以開，還要另外處理PHP執行問題。預設文件設定只決定入口選擇，不能替你修復程式依賴、資料庫連線或PHP版本不相容。把不同結果記下來，才能判斷下一步查哪一層。 到寶塔目標站點查看預設文件 寶塔官方步驟是進入網站清單，選中要管理的站點，再打開預設文件。文件列出常見名稱，包括index.php、index.html、index.htm及default系列，也允許加入自訂文件，例如1.html。 這份名稱清單不是所有現有站點都以相同順序提供首頁的保證。網站可能已經被修改過，伺服器類型及其他配置也可能不同。應以目標站點當前設定和最後生效的服務配置為準，不只看文章裡列出的名稱。 修改之前保存原清單，先確認你想使用的入口檔案確實存在於公開目錄。新增一個不存在的名稱，不會讓Web伺服器自動產生對應首頁。自訂檔名也要和部署方式一致，不能只改面板欄位，卻沒有上傳真正的文件。 Nginx會按index清單順序找檔案 Nginx官方index模組處理以斜線結尾的請求，index指令可以列出多個候選文件，並按指定順序檢查。以下只用來說明順序；實際站點要查看它自己的server或location上下文。 index index.html index.php; 在這個示例中，若index.html存在，就可能先選中它，而不是後面的index.php。若你的目標是PHP程式，先查清楚為什麼保留HTML入口，再決定調整順序、移出舊檔或採用其他部署安排。不要一概宣稱寶塔永遠先選PHP。 Nginx文件也提醒，選中索引文件會造成內部轉交，後續可能由另一個location處理。因此，查看根目錄的index值之後，還要確認被選中的檔案如何處理，尤其是PHP入口，不把選中檔案和成功執行程式當成同一件事。 Apache則核對DirectoryIndex 若網站使用Apache，官方mod_dir文件以DirectoryIndex設定目錄入口，可以列出多個資源，選取第一個找到的候選。這是Apache的規則，不能把Nginx的index指令直接貼進Apache配置。 也注意同一上下文中多個DirectoryIndex指令可能累加清單，而不是你想像的後面一行覆蓋前面一行。讀配置時，要把相關設定放在一起核對；只抄最後一行，可能漏掉原本仍在清單中的入口。 沒有找到入口時，是否產生目錄列表取決於相關設定。不要為了解決首頁問題就打開目錄瀏覽，讓訪客看到原本不應公開的檔案清單。先把正確入口、公開目錄和服務規則查清楚，再處理必要變更。 分清入口問題與路由問題 如果根目錄能開，但程式內頁404，不代表再增加幾個首頁檔名就能修好。框架路由通常還需要把特定請求交給入口程式；預設文件主要解決目錄請求的入口選擇，兩者責任不同。 相反地，如果所有網址都回到某張舊維護頁，也要核對是否有轉址、維護規則或代理服務。先看回應狀態和網址是否改變，再回到檔案入口。不要只因首頁內容舊，就在沒有證據時修改每一段路由配置。 寶塔網站目錄與運行目錄也會影響你正在查哪組檔案。若網站已指向public，應查看public裡的候選入口，而不是專案根目錄中的同名文件。把生效路徑記清楚，避免修改到不參與服務的舊副本。 變更後查看回應，別把快取當成配置未生效 瀏覽器或中間快取可能保留先前回應。MDN的Cache-Control文件說明，回應可以具有不同的儲存與重新驗證條件；看到舊畫面時，應核對實際回應及快取資訊，而不是立刻再改一次預設文件。 記錄測試網址、時間、狀態碼及實際內容，必要時使用合適的重新驗證方式核對。不要為了測一張首頁，直接清除全站或其他網站的快取，也不要把隨便增加查詢參數當成所有代理都必定繞過快取的保證。 確認新入口正常後，再安排舊文件的保存或移除。保留可回復的原設定和檔案版本，讓維護者知道這次改的是候選順序、文件內容，還是公開目錄；日後出現相似問題，就不必重新猜測整個部署過程。 用小範圍核對完成首頁切換 至少分別查看根目錄、明確入口檔名、一個靜態資源及一條合法內頁，核對它們是否符合預期。這不是要求所有網址都顯示同一內容，而是確認首頁切換沒有讓其他請求走錯入口。 如果網站有多個正式域名，也分別核對各自選中的站點。相同IP不代表各域名使用相同配置；不要用其中一個域名的成功結果，替另一個尚未檢查的入口作結論。 交接時附上改動前後的候選文件清單，並說明哪個文件仍保留作回復使用。若之後更新工具又產生同名HTML，就能辨認它可能再次參與入口選擇，先查實際排序，而不是直接認定PHP程式更新失敗。 參考資料寶塔官方：預設文件Nginx：index文件與選擇順序Apache：DirectoryIndexMDN：Cache-Control寶塔官方：網站目錄

寶塔已新增MySQL資料庫，網站仍提示無法連線，先分清資料庫名稱、登入帳號、密碼與連線主機。它們可能在建立時使用相似字串，但各自負責不同工作；把某個欄位填對，不代表整組連線資訊已一致。 以下依寶塔與MySQL官方文件整理核對順序，沒有替你的面板建立帳號或修改密碼。先保留錯誤及現有設定，再查真正使用的服務入口，避免為了網站連線失敗就重設整台資料庫的root密碼。 資料庫名稱是資料位置，帳號是登入身分 寶塔新增資料庫頁把資料庫名、使用者名稱、密碼與訪問權限分開。資料庫名用來指定資料所在範圍；使用者名稱是登入資料庫的帳號，不應因面板預設或自己命名相同，就把兩個概念合併。 在程式配置中逐欄核對，不要只比對某一個名稱。也確認程式是否還在讀舊設定、另一個環境檔案或部署後的配置來源；磁碟上看到新值，和正在執行的程式實際使用它，是兩項不同事實。 新增資料庫可以選擇編碼，寶塔文件列出預設utf8mb4。編碼是資料保存及處理條件，不是連線帳號；不要看到編碼選項就以為它能修復密碼錯誤或網路連線問題。 先確認程式究竟連到哪台服務 MySQL官方連線文件把主機、帳號、密碼、端口及資料庫等選項分開。先核對程式指定的主機與入口，避免寶塔管理的是本機資料庫，程式卻仍連到舊主機或遠端服務。 寶塔也支援添加到本機或遠端伺服器，不能只因資料庫名稱出現在面板，就推斷它一定在同一台主機。把服務位置記清楚，再查看對應帳號與資料庫。 在Unix類環境，MySQL客戶端使用localhost通常會選Unix socket，使用127.0.0.1則可走TCP。程式驅動及設定也需要各自核對；不要把兩個字串看起來都代表本機，就一律認為它們使用完全相同的連線方式。 MySQL帳號還包含來源主機條件 MySQL官方帳號名稱文件說明，帳號由使用者名稱與主機名稱組成。因此，相同使用者名稱來自不同主機條件，可以是不同帳號；只知道名稱，不足以確認這次連線會匹配哪一組身分。 核對訪問來源時，要看資料庫服務實際看到的連線來源。容器、代理或不同主機部署可能影響它，不能直接拿你操作瀏覽器的電腦IP，替網站程式的資料庫連線作判斷。 MySQL連線驗證文件進一步說明，服務會按帳號資料與驗證條件處理連線。遇到拒絕時，保留錯誤中的使用者與來源資訊，再對照實際帳號，別先把所有來源都放開。 寶塔訪問權限不代替網路與資料權限 寶塔新增資料庫提供本地伺服器、所有人及指定IP等訪問選項，預設為本地伺服器；官方頁也把所有人標為不安全。若網站確實在遠端，按需要核對限定來源，而不是用全面開放作為通用修復。 帳號允許某個來源，也不表示資料庫服務已對該網路提供連線。服務監聽、網路路徑及既有防火牆仍是不同條件；連線逾時或拒絕時，不能只改帳號密碼。 同樣，通過登入不等於帳號具有應用需要的所有資料操作權限。依程式工作核對必要範圍，避免把一般網站帳號升到最高權限，只為消除某個操作錯誤。 網站帳號密碼與root密碼分開處理 寶塔root密碼文件明確提醒，root是最高權限帳號，需要謹慎操作。網站若使用獨立帳號，重設root不會自動替你修好那個帳號的密碼，也可能影響其他管理用途。 先確認程式使用哪個帳號，再對照相應密碼來源。不要把面板登入密碼、FTP密碼或另一個資料庫使用者的密碼填進網站配置；它們不是同一組身分。 若需要更換網站帳號密碼，先列出使用它的網站與任務，安排相應更新與驗收。只改資料庫端、未同步程式，或只改程式端、未更新真正帳號，都可能讓原本正常的連線失敗。 按錯誤現象查，不用一種操作解決全部 無法抵達服務時，先核對主機、連線方式與網路入口；驗證被拒絕時，查帳號來源與密碼；登入後找不到資料庫或操作被拒絕，則查資料庫名稱及相應權限。這個順序是診斷方向，仍需實際錯誤支持。 不要因為網站顯示通用資料庫錯誤，就直接刪除重建資料庫。資料可能仍完整存在，只是程式使用錯誤入口或身分；保留現場，才能讓維護者核對而不破壞原資料。 也不要把一次管理工具登入成功，當成網站程式一定成功。工具可能使用不同帳號、服務位置或連線方式；比較時把條件列清楚，不用不同環境的成功填補原問題。 核對時保護密碼與連線資訊 MySQL官方連線文件提醒，直接在命令參數提供密碼可能帶來暴露風險。求助時不需要貼完整密碼或可直接登入的連線字串；保存必要錯誤，敏感欄位按既有方式處理。 截圖也要看清楚面板是否顯示密碼。資料庫名稱、帳號來源與錯誤內容可協助診斷，但不代表所有配置都應公開。避免把密碼放進程式庫、文章留言或日誌旁的說明文字。 若多人共同維護，也註明哪次變更由誰安排，避免另一位維護者把已淘汰的密碼或主機地址填回去。可追蹤的更新紀錄，比重複猜測同一組連線資訊更有用。 最後以程式需要的功能驗收 確認連線條件一致後，用合法且範圍明確的網站功能核對。能登入資料庫只是其中一步；程式還需要讀到正確資料庫與內容，不應用另一個空資料庫的成功連線冒充原站恢復。 保存服務位置、資料庫名稱、帳號及限定來源等非敏感對應，另保護密碼來源與更新安排。之後搬站或改部署環境，就能知道哪些連線條件需要一起核對，不會再把資料庫名和登入身分混為一談。 參考資料寶塔官方：新增資料庫寶塔官方：root密碼MySQL：帳號名稱與HostMySQL：連線選項MySQL：連線驗證

在寶塔把域名加入網站，瀏覽器卻仍打不開，先把DNS解析和站點綁定分開查。寶塔裡的綁定，讓伺服器知道這個域名應由哪個站點處理；DNS則讓使用者找到服務入口。完成其中一個，不代表另一個也已正確。 以下依寶塔、DNS服務商與Nginx官方文件整理診斷順序，介面以你的實際版本為準。重點是先找出請求卡在哪個位置，再改對應設定，不把「域名已加入清單」當成網站已對外可用的證據。 先核對網址中的完整主機名稱 先抄下瀏覽器真正打開的網址，分清example.com、www.example.com與其他子域名。它們不是因為看起來屬於同一個網站，就自動具有相同解析或站點綁定。你若只設定example.com，卻一直測www.example.com，就可能在查另一個入口。 也看清楚使用http還是https，以及有沒有自訂端口。寶塔域名管理文件說明，加入域名時每行一個，默認為80端口；若另外指定端口，使用域名加端口的格式。這是面板欄位規則，不表示HTTPS、憑證或其他端口已一併完成。 先不要把所有可能的子域名都加入，試圖碰運氣。只列出網站真正需要服務的名稱，再逐一核對解析、綁定與憑證。泛域名也有自己的匹配規則，不能把星號當成涵蓋所有深度名稱的通用修復方式。 寶塔綁定不會替你完成DNS 寶塔官方域名管理步驟，是進入網站清單，選中目標站點，再管理綁定域名。文件另明確提醒，添加域名後還要到DNS服務商新增解析紀錄。這兩個操作入口不同，不要在寶塔裡反覆刪除重加域名，卻完全沒有查DNS。 到實際管理這個域名的DNS服務商查看紀錄。A用於IPv4位址，AAAA用於IPv6位址，CNAME則指向另一個名稱。先確認名稱和紀錄類型，再看內容是否對應你目前的服務入口，不要拿另一台舊主機的位址繼續測試。 如果同時有A與AAAA，也要核對兩者。只修A但保留不正確的AAAA，仍可能讓使用IPv6路徑的訪客到錯誤位置。這不表示每個網站都需要新增AAAA；只有具備相應IPv6服務時，才安排正確紀錄。 有代理時，解析位址不一定是源站 如果DNS服務商啟用了網站代理，公開解析可能指向代理服務的位址，而不是寶塔伺服器IP。這時不能只因查到的IP和源站不同，就認定解析錯誤。先確認該紀錄的代理狀態，再核對代理如何連回源站。 Cloudflare官方紀錄說明把Name、位址內容、TTL與Proxy status分開列出。使用它時，應一起看這些欄位；若你使用其他服務商，則依該服務的介面與文件核對，不把Cloudflare的名稱直接套到另一家服務。 也不要為了讓解析看起來和源站相同，就隨意關閉代理。代理可能承擔既有網站功能；是否調整應依目前架構和影響範圍決定。先記清楚DNS紀錄、代理狀態與源站地址，讓維護者知道你正在查哪一段。 解析到了伺服器，還要選到正確站點 如果使用Nginx，官方請求處理說明會先依監聽位址與端口選擇符合的服務，再依請求中的Host找相應server_name。若名稱沒有匹配，可能落到該監聽入口的預設伺服器。這解釋了為什麼解析到同一IP，仍可能看到另一個站點或預設頁。 回到寶塔目標網站，確認需要的完整域名確實在它的綁定清單，而不是另一個相似站點。伺服器上有多個網站時，不能只測IP首頁正常，就認定指定域名也會選中同一站點。 若你查看的是Nginx配置，核對server_name和listen所對應的入口；如果網站使用Apache或其他服務，應改看該服務的虛擬主機規則。這篇引用Nginx解釋匹配原理，不把它冒成所有寶塔網站一定使用同一份配置。 按錯誤現象縮小下一步 域名找不到主機，先查DNS名稱與紀錄。連線逾時或拒絕，接著查服務是否在預期端口提供連線，以及既有網路與防火牆規則。能收到頁面卻是另一個網站，則優先核對站點綁定與虛擬主機匹配。 如果HTTP能開，HTTPS卻顯示憑證錯誤，應另外核對該域名的SSL憑證與HTTPS入口。不要把這個問題一律解釋成DNS，也不要因為HTTP成功，就認定HTTPS已具備正確憑證。 同樣，看到404表示已經收到某個HTTP回應，下一步要查路徑與實際選中的站點。它和完全無法解析不是同一個現象。把錯誤畫面、完整網址與發生時間記下來，比只說「網站打不開」更容易交接。 變更後保留可追蹤的核對紀錄 DNS有TTL與快取影響，修改後不要只用同一個舊瀏覽器分頁立即判斷。核對目前解析結果，再用目標域名確認站點內容；若觀察不同，記下使用的查詢入口與時間，避免把不同快取結果當成設定反覆失效。 也不要承諾一定要等固定24小時才生效，或一定在幾分鐘內完成。DNS服務與查詢快取條件不同，應依實際紀錄與結果判斷，而不是用一個時間口號取代核對。 最後以每個正式需要的主機名稱、協定與端口測試，確認收到正確網站內容。保存當時的DNS紀錄和寶塔綁定清單，若下次搬站或換代理，就知道哪些入口必須一起更新，不會只改其中一半。 每個入口分別記錄，不用成功一個代表全部 可以為example.com與www.example.com各記一列：解析紀錄是什麼、是否經過代理、寶塔綁在哪個網站、HTTP與HTTPS各收到什麼內容。這些是核對欄位，不是本篇已替你的網站測出的結果；填入自己現場的觀察，才有排查價值。 兩個名稱都綁到同一站點，也不表示其中一個已自動轉址到另一個。若網站需要統一入口，還要另外安排轉址，先確認目的地與憑證，再決定相關規則。不要把「都能打開」和「已統一正式網址」當成同一項結果。 交給維護者時保留變更前值和核對時間。下一次有人看到舊解析，就能辨認它是先前記錄還是新的現場結果，避免反覆把已淘汰的主機位址填回去。 參考資料寶塔官方：域名管理Cloudflare：DNS紀錄類型與代理狀態Cloudflare：管理DNS紀錄Nginx：server_name匹配Nginx：請求與預設伺服器

寶塔計畫任務看起來已執行，網站資料卻沒有更新，先把「任務被呼叫」「程式回報成功」和「需要的結果已產生」分開核對。執行時間或一句完成訊息，只能提供部分線索，不代表備份、資料更新或通知已按預期完成。 以下依寶塔與程式工具官方文件整理檢查順序，沒有替你的面板建立或執行任務。先確認工作目的，再讀相應紀錄與產物；不要為了讓清單顯示成功，就把真正的錯誤隱藏起來。 先寫出任務完成的判斷條件 備份任務需要可取得的產物，資料更新需要指定內容發生預期變化，通知任務則要核對傳送及必要的接收結果。每種工作的完成條件不同，不能都用「程式跑過」作結論。 寶塔官方計畫任務頁提供網站備份、資料庫備份、Shell腳本及訪問URL等不同工作。先確認你選的是哪種任務，以及它的目標網站、資料庫、目錄或網址；名稱相似也不表示範圍相同。 網站備份和資料庫備份在文件中分開安排，網站文件成功不等於資料庫也已備份。把產物路徑、保留設定及必要內容記清楚，之後才知道哪個結果應由這個任務提供。 核對執行周期與最近一次紀錄 先查看任務配置中的周期，再找相應的執行時間與輸出紀錄。介面及紀錄位置以實際版本為準，不因清單上有任務就直接推斷它已在需要的時間執行。 核對時保留時區與時間範圍。若你期待的是今天的產物，昨天的成功訊息不能替它通過；如果讀到的是較早執行輸出，也不要把它當成修改後的新結果。 手動執行只可驗證當次條件，不代表排程環境也完全一致。帳號、工作目錄、命令路徑及環境變數都可能需要核對；不要因手動終端正常，就直接否定排程裡保存的錯誤。 輸出文字和退出狀態分開看 程式輸出一句成功文字，不一定同時回傳正確狀態；反過來，退出狀態為零也只反映程式自己採用的成功條件。需要核對它判斷了什麼，而不是把零當成業務內容已完成的通用證明。 如果任務呼叫PHP命令，官方exit文件說明，整數可作為退出碼，而字串會輸出訊息後以零退出。因此，使用exit("failed")這種字串，不會因文字寫了failed就自動成為非零失敗狀態。 exit("failed"); // 輸出文字，退出碼為0 exit(1); // 使用非零退出碼 這是PHP官方語意的對照，不是本篇實測寶塔生成的程式，也不是完整任務範本。實際腳本需要在適當位置輸出必要診斷，並按它的錯誤處理規則回報結果。 Python呼叫子程式時，錯誤不會自動等於例外 寶塔腳本庫文件說明，目前支援Python與Shell腳本，且要依返回類型輸出符合預期的值。使用Python呼叫其他命令時，也要核對子程式狀態，不只看主程式最後是否正常結束。 Python官方subprocess.run預設check=False；若要在非零退出時產生CalledProcessError，需使用相應選項或自己檢查returncode。輸出捕捉、退出碼與業務結果是不同資料，應按任務需要處理。 不要只捕捉所有例外再印一句完成，讓真正的失敗消失。若腳本為了清理暫存而繼續執行，也應保留原錯誤和最終狀態，讓維護者知道工作哪一步沒有達到目的。 訪問URL還要核對HTTP與回應內容 如果工作透過HTTP呼叫網站接口，連線完成不等於接口工作成功。先核對狀態碼、回應內容與應用要求；登入頁、錯誤頁或只接受請求的訊息，都不能一律當成資料更新完成。 curl官方手冊說明，預設情況下，HTTP錯誤狀態不一定使curl以失敗退出；可依版本與需要使用相關失敗判斷選項。這是curl命令的規則，不是宣稱寶塔訪問URL內建任務必定使用同一命令或同一選項。 也不要為了核對結果，隨意重新提交會寫入資料的網址。先確認是否可重複執行，以及如何辨認已處理內容，避免排查時產生重複訂單、通知或其他副作用。 回到真正產物核對範圍與時間 備份工作應查看當次生成的文件、時間及必要內容，不能只因目錄裡有一個舊檔就認定新任務成功。資料更新則核對相應紀錄與範圍，不把另一個網站的變化當成這次工作結果。 若輸出提到完成數量，也和實際資料核對。零筆可能是合理結果，也可能是條件錯誤或來源不可用；要依工作目的判斷，不能用同一個固定門檻替所有任務定成功或失敗。 對外服務若只回報接受請求，還需要後續完成證據。保存請求識別資料與狀態查詢方式，讓任務紀錄能對到同一次工作，而不是拿另一筆成功結果填補眼前缺口。 失敗後先保留紀錄，再決定重試 保存原配置、時間、輸出、退出狀態及相關產物，不急著刪除再建立同名任務。重新建立可能讓原證據失去關聯，也可能和原任務同時執行。 重試之前看工作是否仍在執行，以及是否可安全重複。週期短於工作時間時也需要核對重疊風險；不能把執行次數增加當成必定提高可靠度的辦法。 如果需要修改腳本，按寶塔官方提示先檢查內容與可執行條件，再安排範圍明確的變更。不為了診斷單一任務，順手新增日常排程、清理日誌或釋放其他服務資源。 把三層結果留在同一份紀錄 最後分別記錄任務是否觸發、程式如何回報，以及業務結果是否符合預期。沒有證據的部分清楚保留待確認，不把前一層的成功自動延伸到後一層。 交接時附上本次需要的結果與觀察時間，讓下一位維護者知道該核對哪個檔案、資料或請求。這比只留一張「執行成功」截圖，更容易辨認真正完成與仍有缺口的工作。 參考資料寶塔官方：計畫任務寶塔官方：腳本庫PHP：退出狀態與字串Python：子程式狀態curl：HTTP錯誤與退出行為