ASP.NET 應用部署至虛擬主機常見錯誤與快速排查指南

將本地開發的 ASP.NET 應用發佈至共享虛擬主機，常遭遇「Runtime Error」或「Service Unavailable」等錯誤。本文針對兩大高頻問題——自定義錯誤頁面阻擋詳細資訊與框架版本不匹配——提供定位與解決方案。

問題一：瀏覽器顯示「運行時錯誤」，隱藏詳細堆疊追蹤

現象： 頁面提示「出於安全原因，自定義錯誤設置禁止遠程查看詳細信息」。

根因： ASP.NET 預設 customErrors="RemoteOnly"，本機可見詳細錯誤，遠端僅見通用頁面。

解決： 修改應用根目錄 web.config，暫時關閉自定義錯誤以獲取完整堆疊：

<configuration>
  <system.web>
    <customErrors mode="Off" />
  </system.web>
</configuration>

生產環境建議： 定位修復後，改回 mode="RemoteOnly" 並設定 defaultRedirect="Error.html" 友善錯誤頁，避免洩露敏感資訊。

問題二：框架版本不匹配導致應用池崩潰

現象： 上傳後直接報錯，或應用池頻繁回收、登入狀態丟失。

根因： 虛擬主機預設啟用 ASP.NET 1.1/2.0/3.5/4.x 其中單一版本，而本地開發使用不同版本（如本地 4.8，主機僅啟用 2.0）。

排查步驟：

1. 登入主機控制台（Plesk/cPanel/DirectAdmin/自建面板），確認「ASP.NET 版本」或「應用池 .NET CLR 版本」設定
2. 若主機支援多版本切換，將站點綁定至目標版本（如 v4.0）
3. 若主機僅支援單一版本，需將專案降級或升級至該版本：
   - Visual Studio：專案屬性 → Target Framework 修改
   - 修正因版本差異導致的語法/API 不相容（如 HttpRuntime、Membership、Routing 等）
   - 重新編譯發佈

問題三：應用池回收導致 Session 丟失 / "Service Unavailable"

現象： 訪問幾分鐘後自動登出，或間歇性 503。

根因： 共享主機限制應用池記憶體/CPU/閒置超時，頻繁回收工作進程 (w3wp.exe)。

緩解措施 (web.config)：**

<system.web>
  <sessionState mode="StateServer" 
                stateConnectionString="tcpip=127.0.0.1:42424" 
                cookieless="false" timeout="30" />
  <httpRuntime maxRequestLength="102400" 
               executionTimeout="300" 
               requestValidationMode="2.0" />
</system.web>

• 改用 StateServer/SQLServer 儲存 Session，跨進程回收不丟失
• 避免大量記憶體快取，使用分散式快取
• 若頻繁 503，需聯繫主機商調整應用池限制或升級至 VPS/雲主機

部署檢查清單 (上線前自檢)

• [ ] 目標框架版本與主機一致
• [ ] web.config 連線字串、機器金鑰、Session 模式正確
• [ ] 資料庫連線字串指向主機提供的實例/埠
• [ ] 檔案/目錄寫入權限 (App_Data, Uploads, Logs) 已授予網路服務帳號
• [ ] 自定義錯誤頁面配置完成 (mode="RemoteOnly")
• [ ] 移除 debug="true"、Trace、詳細錯誤頁面等開發殘留

虛擬主機環境受限多、不可控因素大，建議關鍵業務優先選擇 VPS/雲主機/容器服務，擁有完整 IIS/應用池/OS 控制權，避免「隔靴搔癢」式除錯。