大多数热点使用无效证书重定向。

浏览器/操作系统使用启发式方法来检测该行为。

通过尝试检索网页http://clients3.google.com/generate_204来确定是在强制门户还是在线

https://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection

MacOS 和 iOS 使用http://captive.apple.com/hotspot-detect.html （感谢@ceejayoz）

例如，android 会显示一个通知，将使用重定向到门户登录页面。

他们中的大多数人只是使用自己的热点证书，并希望用户单击警告并无论如何都要连接。就我个人而言，当我看到这样的警告并且我知道这是一个强制门户时，我会取消请求并输入一个我不关心的HTTPhttp://redirect.me.away URL，然后让门户通过 HTTP 执行其操作。登录后，我重试我的 HTTPS 请求，该请求现在有效。

大多数时候，我会避开他们——填写他们愚蠢的注册表单不值得我花时间，尤其是考虑到他们提供的连接通常很差。也许有一天我们会拥有一个 EAP-Enterprise 热点网络，您只需在其中注册一次，然后您的设备就会使用用户名/密码自动连接，这一切都会在后台无缝运行。

强制网络不能做的一件事是：在返回正确的服务器证书的同时重定向到它自己的页面。原则上，有这些可能性：(a) 根本不重定向 https。(b) 使用自签名证书重定向。(c) 返回自己的证书，所以 https 协商会失败。(d) 立即终止任何与 https 的连接尝试。

自从将 iOS 上的网络代码从 http 切换到 https 后，我发现不止一个强制网络会立即终止任何连接尝试。对于应用程序来说，这将是一个相当强的迹象，表明存在强制网络。然后，该应用程序可以通过访问为此目的提供的 Google 或 Apple 的 URL 之一来使用更好的检测，如果它们没有按预期响应，那么您肯定有一个强制网络。应用程序可以从那里启动浏览器或让用户进入设置。

我不知道浏览器究竟做了什么，但他们可以检测到 https 被拒绝，并自动访问一个转到登录站点的 http 页面。

强制门户本质上充当中间人，将客户端请求重定向到不同的站点（他们的登录页面）。从技术上讲，这与 HTTPS 试图阻止的行为相同，因为这是坏人在不安全的 HTTP 连接上所做的事情。

因此，当您可以从强制门户连接到 HTTPS 站点而没有警告并且之前没有登录到门户时，会发生以下情况之一：

1. 强制门户不会拦截 SSL 流量，但允许它通过。结果，您无需登录即可立即获得目标页面。但是，从提供商的角度来看，这在很大程度上违背了最初拥有强制门户的目的。
2. 您受信任的 CA 列表中的一个 CA，或由这些根 CA 之一验证（直接或间接）的子 CA 是流氓（或被黑客入侵——尽管如果 WiFi 运营商是远程合法的，后者不太可能）。因此，热点要么具有通配符证书（匹配任何服务器名称），要么可以颁发浏览器接受的任意证书。结果，您输入了一个 HTTPS URL，而是在没有任何警告的情况下获得了登录页面。

第二个例子是证书设计中的一个固有弱点：您的浏览器/操作系统供应商（或者，对于公司设备，您的系统管理员）已经在机器上部署了一个 CA 证书，基本上声称“这个 CA 永远不会颁发证书对于任何服务器，该服务器的合法运营商以外的任何人）。除非您手动验证每个 CA 并删除有问题的 CA（这对个人来说几乎是不切实际的），否则您会盲目地相信他们的断言。

如果以上两种情况都不适用，则会发生以下情况之一：

1. 连接将失败（由于服务器无法访问），直到您连接到普通 HTTP 服务器，重定向到登录页面并登录
2. 您将收到有关无效证书的警告：服务器名称不匹配，或者因为证书不是来自受信任的 CA。如果您忽略此警告，您将获得登录页面。