我正在嘗試解決目前僅在生產中出現的網站錯誤。由於我無法刪除該環境，因此我嘗試建立盡可能接近的副本。本網站基於 Kentico 11，在 Amazon EC2 t2 執行個體上的 Windows Server 2019 Datacenter 上執行，並由 RDS SQL Server Web Edition 執行個體提供支援。為了建立測試環境，我對資料庫進行了備份轉儲並將其還原到執行個體上的另一個資料庫，然後建立 EC2 的 AMI 並使用它啟動新的 EC2 執行個體。
這個過程過去已經工作了幾十次，但是這一次，今天到目前為止我已經完成了四次，新實例上的網站將永遠不會返回除了通用 404 狀態（即最小 404 頁面）之外的任何內容由IIS 本身返回，而不是從Kentico 返回）。奇怪的是，這些對副本的請求沒有記錄在其 IIS 請求日誌中。除了 IP 位址和資料庫連接字串等詳細資訊之外，我看不到生產實例和副本之間有任何不同，而且我無法想像有任何差異的原因；我在啟動新執行個體前幾分鐘建立了 AMI。我花了一整天的時間再次嘗試和谷歌搜索，直到我的手指麻木......有沒有人對為什麼副本不能按預期工作或如何實現它有任何想法或建議？
編輯：想知道如果 IIS 沒有回應 HTTP 請求，我查看了回應標頭，其中包括：Server: Microsoft-HTTPAPI/2.0。我找到了這個：https://docs.microsoft.com/en-us/windows/win32/http/http-api-start-page這實際上只會加深謎團。 IIS 遇到了什麼問題以及如何處理？再說一遍，由於該實例是從基於工作站點的 AMI 啟動的，那麼這種變化是如何產生的呢？
編輯：為了更清楚，我更新了標題
答案1
經過一番挖掘後網路統計和任務清單並確定系統進程是響應連接埠 80 和 443 上的請求的，我有一個我應該早點想到的想法，並查看創建一個進程時會發生什麼本機正在複製的生產伺服器上的請求。令我驚訝的是，這是同一件事：404 返回的東西將自己標識為Microsoft-HTTPAPI/2.0...最後我想到這可能與 IIS 連接埠綁定中的主機名稱有關。
果然，當我編輯這些綁定以匹配複製主機的 DNS 名稱（而不是正在複製的伺服器的名稱）時，請求由 IIS 處理，並且就 Web 服務而言，一切都恢復正常。
另一個警示故事是關於一個缺乏管理經驗的開發人員必須嘗試解決管理端謎團的故事。