cmcc.wifi http 访问被强制 https

在咖啡馆连上CMCC热点打开网页，结果页面自动跳转到HTTPS，导致一些内网设备或测试页面彻底打不开。很多人第一反应是关掉浏览器重开或者切换飞行模式，但只要HTTP请求再次发出，跳转就会原封不动地回来。根本原因并非浏览器或手机，而是CMCC的Portal认证网关在HTTP响应头里注入了强制HTTPS的301/302跳转代码。本文会从原理讲到操作，帮你把这条强转规则在本地链路里彻底绕开。

一、CMCC强制HTTPS到底卡在哪一层

CMCC作为运营商级的WiFi方案，其认证门户（Captive Portal）通常部署在AC控制器或上层网关。当用户首次发起HTTP请求时，网关会插入一段重定向响应，把原始URL替换为登录页面的HTTPS地址。理解这一点，就明白为什么单纯清理浏览器缓存、切换UA或开启无痕模式都无效——因为HTTP报文根本没有抵达目标服务器。

1.1 三种典型的强制HTTPS场景

场景一：Portal认证页强转。未认证用户访问任意HTTP站点，CMCC会将其302到https://login.cmcc.cn/类似的登录页面，完成认证后才会放行。

场景二：AC策略头注入。部分省份的CMCC后台会下发Strict-Transport-Security头，导致浏览器在缓存期内对所有子域名强制HTTPS，即使本地网络已切换也无济于事。

场景三：DNS劫持叠加。CMCC的DNS在解析HTTP域名时直接返回网关IP并附带302，配合前两者形成“多重保险”。此时手动指定114.114.114.114或223.5.5.5作为DNS可以缓解部分症状，但无法根治。

二、为什么普通方法全部失灵

很多用户尝试过关闭浏览器HSTS、清空SSL状态、甚至修改手机hosts文件，但这些操作都只能影响终端侧，而CMCC的强制HTTPS发生在网络层或应用层网关。要真正解决，必须从两个方向切入：要么绕开CMCC的Portal链路，要么在本地路由器层面建立独立隧道。

2.1 浏览器侧的局限

HSTS策略一旦被网关写入，浏览器会拒绝降级回HTTP。而DoH（DNS over HTTPS）功能在部分新版本系统里默认开启，导致DNS查询也走了加密通道，传统hosts编辑工具失效。所以单靠调整客户端配置，几乎不可能突破CMCC的封锁。

2.2 路由器侧的优势

如果你随身携带一个便携路由器并以客户端模式接入CMCC，那么所有HTTP重定向都只会作用于这台路由器本身，连接在路由器下的设备走的是二级NAT。此时只要在路由器后台关闭DoH、关闭HSTS预加载，或直接建立VPN隧道，就能让下挂设备自由访问HTTP资源。

三、四步实操：在路由器上彻底绕开强制HTTPS

下面以常见的GL.iNet便携路由器为例，步骤适用于OpenWrt衍生系统，其他品牌可参考对应菜单。

3.1 第一步：切换DNS并关闭DoH

登录路由器后台（通常地址192.168.8.1，账密admin/admin），进入「网络 - DNS」。把首选与备用DNS改为223.5.5.5和119.29.29.29，并确认「DNS over HTTPS」开关处于关闭状态。这一步能切断CMCC的DNS劫持叠加效应。

3.2 第二步：禁用Portal认证探测

在「网络 - 防火墙」或「Captive Portal」相关选项里，找到「检测网络连通性」并将其关闭。很多路由器默认会向http://captive.apple.com等地址发起探测，被CMCC捕获后会触发Portal跳转。关闭后，路由器自身不再暴露HTTP请求，下挂设备的探测行为也被抑制。

3.3 第三步：建立VPN或SSH隧道

对于仍需要访问公网HTTP的用户，建议在路由器上启用WireGuard或OpenVPN客户端，将流量整体加密转发。这样HTTP请求在CMCC眼里就变成了HTTPS隧道内的私有数据，强制HTTPS机制无从下手。若不便搭建服务器，使用「Clash」等工具的「全局直连」模式也能达到类似效果。

3.4 第四步：浏览器端补充清理

在已成功连通的设备上，打开Chrome访问chrome://net-internals/#hsts，在「Delete domain security policies」处输入cmcc.cn并删除残留策略。同时进入「设置 - 隐私与安全 - 安全」，关闭「使用安全DNS」。这是双保险，确保路由器侧的操作不被浏览器缓存抵消。

四、方案对比：哪种最适合你

轻量需求（仅测试本地HTTP服务）：仅执行第一步关闭DoH即可，配合hosts文件直接指向局域网IP，零成本解决。

中度需求（频繁访问内网后台）：建议完成前两步，让路由器彻底脱离CMCC的Portal探测链路，下挂设备访问192.168.1.1等内网HTTP页面不再被劫持。

重度需求（需要完整公网HTTP）：必须走VPN隧道方案，虽然增加延迟，但换来的是彻底自由的协议栈。注意选择支持UDP的隧道协议，避免被运营商QoS策略二次降速。

总结来看，CMCC强制HTTPS的本质是Portal网关在HTTP响应头里做了手脚，单纯在终端侧挣扎毫无意义。把战场转移到本地路由器，先切断DNS劫持，再关闭Portal探测，最后用加密隧道包裹流量，三步组合拳下来，绝大多数HTTP访问都能恢复正常。你平时连接公共WiFi时，最头疼的是哪种强制跳转？欢迎在评论区聊聊你的遭遇。