Ad-Hoc WLAN搭配本地HTTP服务时多系统设备误触发WiFi登录提示问题

• 全局DNS重定向规则覆盖所有域名：你在路由侧配置的未认证用户流量拦截规则，首先会劫持所有终端的DNS查询请求，把包括captive.apple.com、msftncsi.com等系统探测域名在内的所有域名，全部解析到你本地Web服务的IP地址，因此终端发起的探测请求自然会直接发送到本地服务，而不是公网对应服务器。
• 端口流量拦截规则转发所有HTTP/HTTPS请求：哪怕你没有配置DNS劫持，只要你在iptables、nftables等防火墙配置中，将所有未认证设备的80、443端口流量全部DNAT到本地Web服务的对应端口，不管终端解析到的探测域名对应什么公网IP，流量都会被强制转发到本地服务。
• 无公网路由触发终端适配逻辑：由于你的Ad-Hoc网络没有接入互联网，终端无法获取到有效的公网路由，部分系统的 captive portal 探测逻辑在DNS请求超时、无默认网关的场景下，会自动将探测请求直接发送到当前WiFi网络的网关IP（也就是你的树莓派设备IP）。

根据你的业务需求，可以选择以下两种方案：

方案一：保留WiFi登录提示，优化探测流程 #

如果你需要系统继续将该网络识别为需要认证的公共WiFi，保持登录提示弹出的逻辑：

• 针对三类系统的探测地址单独配置响应规则，仅对已完成认证的设备返回对应成功响应：
  • 苹果iOS/macOS：对captive.apple.com的请求返回HTTP 200状态码，响应内容为<HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>
  • 微软Windows：对www.msftncsi.com/ncsi.txt的请求返回HTTP 200状态码，响应内容为纯文本Microsoft NCSI
  • 谷歌安卓/Chrome：对google.com/generate_204的请求返回HTTP 204状态码，不需要携带响应内容
• 未认证设备访问上述探测地址时，仍然正常重定向到登录页，既符合系统探测逻辑，也不会打断原有认证流程。

方案二：关闭WiFi登录提示，直接开放本地服务 #

如果你不需要弹出登录提示，希望设备连接后直接访问本地服务：

• 对所有设备（无论是否认证）访问三类探测地址的请求，直接返回上述对应成功响应。系统检测到连通性探测成功后，就不会弹出登录提示，也不会标记网络为需认证状态。
• 可选优化：关闭全局DNS劫持和80/443端口全局重定向规则，仅对访问非本地IP段的请求做重定向，避免误拦截本地服务的访问请求。

内容的提问来源于stack exchange，提问作者markus