有没有办法在 windows 热点上实施强制门户？
Is there a way to implement captive portal on windows hotspot?
我正在寻找一种方法来为 windows 10 - 移动热点实施强制门户。这个想法是将连接到热点的所有设备重定向到网页。
我找到了这个 article，它在 linux 中展示了如何做到这一点。
但我一直未能找到 windows 的类似版本。类似 this 的帖子被证明是死胡同。
如果需要，我可以使用简单的 nginx 服务器向客户端提供 302 重定向响应，但不喜欢使用任何现有的实现强制门户的软件。
更新
我已使用变通方法在客户端（linux 笔记本电脑、android 设备等）上成功触发强制门户。
每当设备连接到热点时，它都会向一些预定义的网站发送请求，以检查 wifi 连接是否可以访问互联网。如果它收到 302 响应，它会生成强制门户 window.
所以我在 windows 机器上的主机文件中添加了以下条目。
127.0.0.1 clients3.google.com #android
127.0.0.1 connectivitycheck.gstatic.com #android
127.0.0.1 nmcheck.gnome.org #ubuntu
然后这些请求将使用主机文件条目在本地解析并发送到 nginx 服务器，该服务器为所有 http 请求提供 302 重定向。
我在上面的 UPDATE 中提到的设置最终被调整到我想要的位置。我使用了 dnschef，一个开源的 dns 服务器，可以完美地用作命令行客户端。
接下来的步骤。
启动windows移动热点。
转到网络适配器 => Select 热点适配器 => 更改 IPv4 设置 => 将 127.0.0.1 设置为 DNS 服务器。
- 使用
--fakeip = 192.168.137.1 启动 dnschef
- 在 192.168.137.1 上启动一个 http 服务器，并对所有请求给予 302 重定向响应。
就是这样！每当设备连接到热点时，它都会尝试连接到任何一个用于确定互联网连接的预设网站。这些请求将由 dnschef 在本地解析到我们的 Nginx 服务器。 Nginx 服务器然后提供 302 重定向，触发客户端上的强制门户。
我使用 dnscrypt-proxy 尝试了类似的方法，它提供专门的 captive-portal 支持。因为，这只不过是 dns 伪装，有几种方法可以实现，对某些“connection-checking”域的请求被定向到本地网络服务器。
与接受的答案不同，我找到了一种更简单、更灵活的方法，即使用 windows 主机文件 ，而不使用任何 third-party dns 代理.我没有将 connection-checking 域与本地主机相关联，而是将它们映射到物理 wifi 接入点 IP 地址（即 192.168.137.1）。这会导致 wifi 客户端直接将其 connection-checking 请求发送到网络服务器，即本地 pc 上的 运行 并侦听端口 80 上的所有连接。
主机文件：
192.168.137.1 captive.apple.com
192.168.137.1 clients3.google.com
192.168.137.1 nmcheck.gnome.org
192.168.137.1 connectivitycheck.gstatic.com
192.168.137.1 connectivitycheck.android.com
192.168.137.1 www.msftncsi.com
192.168.137.1 dns.msftncsi.com
192.168.137.1 www.msftconnecttest.com
192.168.137.1 ipv6.msftconnecttest.com
192.168.137.1 ipv4only.arpa
此网络服务器（在我的例子中是 asp.net 核心）将客户端重定向到登录页面，除非它们已经注册。在这种情况下，网络服务器可能会像“真实”服务器一样响应调用，这些服务器位于那些 connection-checking 域之后，以便不重定向已经成功登录的客户端。
我正在寻找一种方法来为 windows 10 - 移动热点实施强制门户。这个想法是将连接到热点的所有设备重定向到网页。
我找到了这个 article，它在 linux 中展示了如何做到这一点。
但我一直未能找到 windows 的类似版本。类似 this 的帖子被证明是死胡同。
如果需要，我可以使用简单的 nginx 服务器向客户端提供 302 重定向响应，但不喜欢使用任何现有的实现强制门户的软件。
更新
我已使用变通方法在客户端（linux 笔记本电脑、android 设备等）上成功触发强制门户。
每当设备连接到热点时，它都会向一些预定义的网站发送请求，以检查 wifi 连接是否可以访问互联网。如果它收到 302 响应，它会生成强制门户 window.
所以我在 windows 机器上的主机文件中添加了以下条目。
127.0.0.1 clients3.google.com #android
127.0.0.1 connectivitycheck.gstatic.com #android
127.0.0.1 nmcheck.gnome.org #ubuntu
然后这些请求将使用主机文件条目在本地解析并发送到 nginx 服务器，该服务器为所有 http 请求提供 302 重定向。
我在上面的 UPDATE 中提到的设置最终被调整到我想要的位置。我使用了 dnschef，一个开源的 dns 服务器，可以完美地用作命令行客户端。 接下来的步骤。
启动windows移动热点。
转到网络适配器 => Select 热点适配器 => 更改 IPv4 设置 => 将 127.0.0.1 设置为 DNS 服务器。
- 使用
--fakeip = 192.168.137.1 启动 dnschef
- 在 192.168.137.1 上启动一个 http 服务器，并对所有请求给予 302 重定向响应。
就是这样！每当设备连接到热点时，它都会尝试连接到任何一个用于确定互联网连接的预设网站。这些请求将由 dnschef 在本地解析到我们的 Nginx 服务器。 Nginx 服务器然后提供 302 重定向，触发客户端上的强制门户。
我使用 dnscrypt-proxy 尝试了类似的方法，它提供专门的 captive-portal 支持。因为，这只不过是 dns 伪装，有几种方法可以实现，对某些“connection-checking”域的请求被定向到本地网络服务器。
与接受的答案不同，我找到了一种更简单、更灵活的方法，即使用 windows 主机文件 ，而不使用任何 third-party dns 代理.我没有将 connection-checking 域与本地主机相关联，而是将它们映射到物理 wifi 接入点 IP 地址（即 192.168.137.1）。这会导致 wifi 客户端直接将其 connection-checking 请求发送到网络服务器，即本地 pc 上的 运行 并侦听端口 80 上的所有连接。
主机文件：
192.168.137.1 captive.apple.com
192.168.137.1 clients3.google.com
192.168.137.1 nmcheck.gnome.org
192.168.137.1 connectivitycheck.gstatic.com
192.168.137.1 connectivitycheck.android.com
192.168.137.1 www.msftncsi.com
192.168.137.1 dns.msftncsi.com
192.168.137.1 www.msftconnecttest.com
192.168.137.1 ipv6.msftconnecttest.com
192.168.137.1 ipv4only.arpa
此网络服务器（在我的例子中是 asp.net 核心）将客户端重定向到登录页面，除非它们已经注册。在这种情况下，网络服务器可能会像“真实”服务器一样响应调用，这些服务器位于那些 connection-checking 域之后，以便不重定向已经成功登录的客户端。