我的瀏覽器不會顯示 http://小號___s在b.sub.example.com
當我進入
http://sub.example.com瀏覽器時，我收到*“連接被拒絕”* 消息或*“證書無效”*錯誤，但我什至不想通過 https 連接。據我所知：
- Web 伺服器配置正確
sub.example.com- TCP 埠 80 在防火牆/安全組中打開
- URL 中使用純 HTTP 而不是 HTTPS
sub.example.com指向 Web 伺服器正確 IP 地址的DNS 記錄- 使用新配置重新啟動 Web 伺服器
- 日誌不顯示啟動或任何其他錯誤
我該如何調試，那裡有什麼問題？
首先要注意的是，現代 Web 瀏覽器可能不是調試此類問題的最佳工具。瀏覽器甚至可能是它們的原因，因為伺服器可以完全正確配置，問題可能是 100% 客戶端。
內容：
- 測試（使用
curl隱身/匿名瀏覽器）- 兩個測試都顯示了預期的內容
curl可以，但私人瀏覽器視窗不顯示正確的內容- 兩個測試都沒有顯示預期的內容
測試
嘗試不僅使用 FQDN 進行測試，
http://sub.example.com而且使用更完整的 URL，例如http://sub.example.com/some-page.html. 當您知道您在代理後面時，添加其他參數通常會繞過記憶體的內容，即添加和遞增計數器，例如http://sub.example.com/some-page.html?test=3
- 從“私人/隱身”瀏覽器視窗進行測試。
這減少了基於記憶體對象得出錯誤結論的可能性。
- 例如，從命令行（在測試伺服器上）進行測試，
curl -vv http://sub.example.com/some-page.html或者使用telnet並模擬 Web 請求遠端登錄 sub.example.com 80
GET /some-page.html HTTP/1.1
主機：sub.example.com
curl在輸出中尋找的東西：
- 在調試伺服器問題時，代理設置絕對是一個危險信號和真正的障礙。代理伺服器可以記憶體（DNS 記錄和 Web 內容）、限制您的訪問，甚至替換 TLS 證書。
curl -vv http://sub.example.com/some-page.html * Uses proxy env variable no_proxy == 'localhost,127.0.0.1,.corp.example.net' * Uses proxy env variable http_proxy == 'http://[user]:[pass]@proxy.corp.example.net:8080/' * Trying 10.2.0.80:8080... ^^^ Danger - Proxy server
- 如果您想正確測試 Internet Web 伺服器的配置，請從不依賴代理伺服器的（測試）系統進行測試。我通常沒有支持成熟瀏覽器的測試系統，但我通常可以管理一個從命令行執行 curl 命令的系統。
curl -vv http://sub.example.com/some-page.html * About to connect() to sub.example.com port 80 (#0) * Trying 192.168.2.119... * Connected to sub.example.com (192.168.2.119) port 80 (#0) ^^^ CHECK is this the correct IP-address of your webserver? > GET /some-page.html HTTP/1.1 > User-Agent: curl/7.29.0 > Host: sub.example.com > Accept: */*在那裡，您觀察到與 Web 伺服器的正確 IP 地址和埠的連接已成功建立。該
>標記位於 curl 生成的請求標頭之前。伺服器響應標頭用
<標記標記，然後在空行之後由伺服器發送響應正文：< HTTP/1.1 302 Found | ^^^ The server HTTP STATUS response code `^^ the HTTP protocol version < Date: Mon, 07 Feb 2022 13:58:11 GMT < Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.4.16 < Location: https://sub.example.com/some-page.html < Content-Length: 216 < Content-Type: text/html; charset=iso-8859-1 < <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> ...在第一個協議頭之後 是 伺服器生成
HTTP/1.1的HTTP 狀態程式碼。響應意味著某種2xx形式的成功，3xx響應是重定向（見此處），4xx並且5xx是錯誤。在此範例中，伺服器發送的其他標頭
Location:中指示重定向響應的目標。兩個測試都顯示了預期的內容
結論： Web 伺服器配置正確，問題與瀏覽器有關。
最可能的原因：在更改 Web 伺服器配置之前可能已經配置了永久重定向，並且永久重定向 (301) 被瀏覽器記憶體。相當常見的是記憶體損壞的重定向或記憶體到 https 的重定向，並且
sub.example.com尚未配置證書和 https 站點。**解決方案 1：**清除瀏覽器記憶體，網站應按預期載入。
**解決方案 2：**獲取 sub.example.com 的 SSL 證書並啟用 TLS。
**原因 2：**根本原因不完全相同，但與記憶體重定向到 https 的因果關係實際上相似，域設置的HTTP 嚴格傳輸安全(HSTS) 策略
example.com也適用於範例的所有（新）子域。 com。任何合理的現代瀏覽器都會儲存和遵守 HSTS 策略，並且會拒絕通過普通 http 連接到埠 80，並且會默默地重寫http://sub.example.comURLhttps://sub.example.com並嘗試使用 TLS 連接到埠 443。**解決方案：**獲取 sub.example.com 的 SSL 證書並啟用 TLS。
清除 HSTS 瀏覽器記憶體可以暫時起作用，但僅當您同時從 example.com 中刪除包含子域 HSTS 策略時才有效，不建議這樣做。
curl可以，但私人瀏覽器視窗不顯示正確的內容結論： Web 伺服器配置正確，問題與瀏覽器或客戶端有關。
**原因 1：根本原因不完全相同，但與記憶體的HTTP 嚴格傳輸安全(HSTS) 策略實際上相似的原因和影響是HSTS 預載入列表上的域。**但是，如果在“私人/隱身”視窗中不應遵守記憶體的 HSTS 策略，則應始終應用 HSTS 預載入列表，即使在私人/隱身視窗中也是如此。
有關如何確定您的域或 TLD 是否在 HSTS 預載入列表中的概述，請參閱此問答：
需要 HTTPS 連接的頂級域 (TLD) 列表，例如 .dev
**解決方案：**獲取 sub.example.com 的 SSL 證書並啟用 TLS。
**原因 2：**雖然 DNS 記錄配置正確，但客戶端解析器（執行瀏覽器的桌面）可能指向不同的 IP 地址。例如檢查客戶端名稱伺服器解析
nslookup的dig內容，不要忘記 sub.example.com 的主機文件條目將覆蓋 DNS。**解決方法：**刪除 sub.example.com 的hosts 文件條目，或進一步調查 DNS 差異。
兩個測試都沒有顯示預期的內容
**結論：**問題出在伺服器端，而不是客戶端。
沒有反應
請參閱 導致“連接被拒絕”消息的原因是什麼？當 Web 伺服器似乎在埠 80 上根本沒有響應時。
重定向響應
當 Web 伺服器確實響應時，請仔細查看該響應：
< HTTP/1.1 302 Found < Date: Mon, 07 Feb 2022 13:58:11 GMT < Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.4.16 < Location: https://sub.example.com/some-page.html < Content-Length: 216 < Content-Type: text/html; charset=iso-8859-1 < <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> ...對於配置為將純 HTTP 重定向到 HTTPS 的 Web 伺服器來說，這是一個相當典型的響應。
第
302 Found一個標頭中的狀態程式碼表示臨時重定向。對於將是301 Moved Permanentlyhttp 狀態標頭的永久重定向。標
Location:頭顯示客戶端重定向到的位置。原因：當未在 Web 伺服器配置中定義時，Web 應用程序生成重定向到 https 或完全不同的域是很常見的。
在 Apache Web 伺服器（允許它們）上，
.htaccess文件也可以是重定向的來源。**解決方法：**調整或移除重定向，或者確保重定向生效並且重定向的目標有響應。
經常：獲取 SSL 證書並啟用 TLS！
**原因：**重定向的目標經常被破壞，檢查那裡是否有細微的錯字，我看到缺少
/重定向到sub.example.comsome-page.html和錯誤使用的參數重定向到http://some-page.html，或http://wwww.example.com/http://sub.example.com/some-page.html類似的。還可以通過向多個重定向級別發出請求來測試循環，這
Location:通常也表明配置損壞並刪除循環。來自不同網站的內容
當您看到來自您託管的不同站點的內容而不是內容時，請
sub.example.com注意大多數 Web 伺服器將在無法將主機名與特定站點匹配時顯示來自預設站點的內容。**解決方法：**重新檢查您的配置是否存在拼寫錯誤，並確認 Web 伺服器已使用更新的配置重新啟動。