☰

测试

tag-icon • tag-icon nginx ssl apache-2.4 web-server hsts
测试

http://sub.example.com当我在浏览器中访问时，我得到了“连接被拒绝” 消息或“证书无效”错误，但我甚至不想通过 https 连接。

据我所知：

  • Web 服务器已正确配置sub.example.com
  • 防火墙/安全组中已打开 TCP 端口 80
  • URL 中使用了纯 HTTP 而非 HTTPS
  • DNS 记录指向sub.example.comWeb 服务器的正确 IP 地址
  • Web 服务器已使用新配置重新启动
  • 日志未显示启动或任何其他错误

我该如何调试以及那里存在什么问题？

答案1

首先要注意的是，现代网络浏览器可能不是调试此类问题的最佳工具。浏览器甚至可能是导致这些问题的原因，因为服务器可以完全正确配置，问题可能完全出在客户端。

内容：

  • 测试（使用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 请求

    telnet 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

  • 如果您想正确测试互联网 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 服务器配置之前可能已配置了永久重定向，并且永久重定向（301）被浏览器缓存。相当常见的是缓存损坏的重定向或缓存的重定向到 https 并且尚未sub.example.com配置证书和 https 站点。

解决方案 1：清除浏览器缓存后网站应该可以正常加载。
解决方案 2：获取 sub.example.com 的 SSL 证书并启用 TLS。

原因 2：虽然根本原因并不完全相同，但实际上与缓存重定向到 https 的因果关系类似，HTTP 严格传输安全域设置的 (HSTS) 策略example.com也适用于 example.com 的所有 (新) 子域。任何较新的浏览器都会存储并遵守 HSTS 策略，并会拒绝通过纯 http 连接到端口 80，并会默默地重写 URLhttp://sub.example.com并https://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端名称服务器解析的内容，不要忘记hosts 文件sub.example.com 的条目将覆盖 DNS。

解决：去除hosts 文件sub.example.com 的条目，或者进一步调查 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 服务器配置中没有定义时，网络应用程序生成重定向的情况很常见到 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 服务器已使用更新的配置重新启动。

相关内容