我们的一个内部应用程序可通过以下示例域名地址访问：
https://some-addres.some-domain:8443
对于以下所有情况：
- https://some-addres.some-domain:8443(各 200)
- http://some-addres.some-domain:8443（307 指向 https）
- some-addres.some-domain:8443（分别为 200）
我们最终进入了正确的 SSL 应用程序页面。但是，当我们尝试通过 IP 地址（假设为 1.2.3.4）访问它时，会发生以下情况：
- https://1.2.3.4:8443（分别为 200 但没有 SSL）
- http://1.2.3.4:8443（无响应，失败）
- 1.2.3.4:8443（分别为 200，但没有 SSL）
我不是系统管理员，基本上我无法访问此特定实例的任何配置，我只是好奇，域名和 IP 地址最终是同一个东西，怎么可能表现得如此不同？这取决于服务器配置还是这是 RFC/其他规范的一部分？
谢谢你的帮助！
答案1
你做有 SSL/TLS 连接 – 如果客户端尝试使用 TLS，服务器不能简单地返回非 TLS 响应，它必须使用 TLS 响应或终止连接。您根本无法成功验证您正在连接到正确的服务器。
TLS 中的服务器通过证书进行标识，该证书必须与您尝试访问的 URL 匹配– 该证书仅对其最初颁发的名称有效，并且不会自动对相应的 IP 地址或任何其他变体有效。
例如，当您尝试访问时
https://1.2.3.4:8443，证书必须在其 subjectAltNames 中明确列出 iPAddress 1.2.3.4。就您而言，很可能它没有列出 IP 地址，而只列出了完整的域名。看RFC 2818 第 3.1 节“服务器身份”：
通常，HTTP/TLS 请求是通过取消引用 URI 生成的。因此，客户端知道服务器的主机名。如果主机名可用，客户端必须根据服务器证书消息中显示的服务器身份对其进行检查，以防止中间人攻击。
[...] 在某些情况下，URI 被指定为 IP 地址而不是主机名。在这种情况下，iPAddress subjectAltName 必须存在于证书中，并且必须与 URI 中的 IP 完全匹配。
此外，TLS 客户端告诉服务器您尝试访问的地址，服务器可以根据该地址返回不同的证书。（例如，在 Apache 或 Nginx 中配置 HTTPS 站点时，每个 <VirtualHost> 可以具有不同的 SSLCertificateFile 参数 - 因此它可以使用包含 5 个域的单个证书，也可以为每个域使用 5 个单独的证书。）
因此，也有可能
https://1.2.3.4:8443您在访问时遇到的虚拟主机根本没有正确配置证书（例如，它可能使用默认的虚拟证书）。