我之前折腾过iOS captive portal的类似坑，结合你的场景来拆解问题和给出解决思路：

问题根源分析 #

iOS的系统级captive portal弹窗本质是网络验证窗口，它的核心逻辑是确认当前网络能否访问真实互联网，而非作为常规浏览器窗口使用。你的问题出在：

• 当你在这个弹窗里触发图片保存操作时，iOS会二次检测网络状态，发现依旧无法连接到真实互联网，就直接判定“验证失败”，触发关闭弹窗+断网的逻辑
• 而你手动选择“无互联网使用网络”后，是绕开了系统的captive portal验证流程，用常规浏览器环境处理请求，自然就符合iOS的文件保存逻辑

可行的解决方案 #

1. 让iOS认为网络“已通过验证” #

iOS会在captive portal返回特定响应后，把弹窗的“取消”按钮改成“完成”，标记网络为“可用”，后续操作就不会触发断网。你可以通过调整Flask响应实现：

• 针对iOS的captive portal检测请求（比如/hotspot-detect.html），返回204 No Content响应，告诉系统“验证完成”
• 在图片页面的响应中添加iOS识别的专属头

修改你的Flask代码：

from flask import request, redirect, make_response, render_template

def _redirect_to_main():
    # 识别iOS的captive portal检测请求
    user_agent = request.headers.get('User-Agent', '')
    if 'CaptiveNetworkSupport' in user_agent:
        # 返回204让iOS标记网络为已验证
        return '', 204
    # 其他请求正常重定向到图片页面
    return redirect('/')

def _image_delivery():
    # 渲染你的图片展示页面
    resp = make_response(render_template('photo_page.html'))
    # 添加iOS captive portal兼容头
    resp.headers['X-Apple-Captive-Portal'] = 'true'
    return resp

2. 调整captive portal的网络配置 #

你的现有dnsmasq和iptables配置可以再优化，覆盖iOS所有的检测逻辑：

• 在dnsmasq中补充更多iOS常用的检测域名，确保所有系统级检测请求都指向你的Flask服务

# 在/etc/dnsmasq.conf中添加
address=/apple.com/192.168.4.1
address=/icloud.com/192.168.4.1
address=/itunes.apple.com/192.168.4.1
# 保留你原来的检测域名配置

• 给dhcp添加网关和DNS参数，确保iOS获取正确的网络参数

# 在dnsmasq.conf的dhcp配置段添加
dhcp-option=3,192.168.4.1  # 设置网关
dhcp-option=6,192.168.4.1  # 设置DNS服务器

3. 优化图片加载方式 #

确保页面中的图片用绝对URL指向你的Flask服务，比如http://192.168.4.1/static/your_photo.jpg，避免相对路径。iOS的captive portal弹窗对相对路径资源的加载逻辑和常规浏览器有差异，可能导致保存时无法正确定位图片资源。

4. 妥协方案：引导用户进入浏览器操作 #

如果上面的配置都没解决问题，可以在captive portal页面顶部添加提示：“请点击右上角「取消」→ 选择「无互联网使用网络」，再在浏览器中打开本页面保存图片”，虽然是妥协，但能保证核心功能可用。

对现有代码的小优化建议 #

• 你的iptables把443端口也重定向到Flask的5000端口，但如果Flask只跑HTTP服务，会导致HTTPS请求出错，建议暂时只重定向80端口，或者给Flask配置自签名HTTPS证书（captive portal场景下iOS会接受不安全证书）
• 可以在dnsmasq日志中查看所有iOS的检测请求，针对性地添加重定向规则，日志路径是/var/log/dnsmasq.log

内容来源于stack exchange