实测 · 2026-07-28
在联通 4G 下打开某论坛，白屏 27 秒后报「net::ERR_CONNECTION_RESET」
我用一台 Redmi Note 12 试了六次，前三次白屏约 27 秒，第四次出现 ERR_CONNECTION_RESET，第五、六次直接跳回首页。同一张 SIM 卡在系统浏览器里同样的站点能开，这让我很难把问题简单归给「网络不好」。
详情 / 收录与整理
昨天下午四点二十分，我在城南那家旧书店翻到一本 2003 年印的《网络故障排查手册》，第 114 页有人用蓝圆珠笔写了一行字：「联通卡，微信能发，网页全白。」我盯着这行字看了很久，回到家又把手机qq浏览器打不开网站这件事重新想了一遍。
实测 · 2026-07-28
我用一台 Redmi Note 12 试了六次，前三次白屏约 27 秒，第四次出现 ERR_CONNECTION_RESET，第五、六次直接跳回首页。同一张 SIM 卡在系统浏览器里同样的站点能开，这让我很难把问题简单归给「网络不好」。
线索 · 2026-07-21
老周是前同事，做渗透测试的。他在 Chrome 的 Network Conditions 里把 User-Agent 换成一串含 MQQBrowser 的字符串，同一 URL 立刻返回 403 与一段 23 字节的纯文本。这条线索说明：有些「打不开」是站点主动拒绝，不是手机的问题。
笔记 · 2026-07-15
我用两部手机分别指定 DNS，同一个域名解析出 172.67.x.x 和 198.18.x.x 两个答案，后者属于一个从未见过的 198.18.0.0/15 段。把第二个 IP 手动塞进 hosts，页面显示的是运营商错误提示页。这算是我收集到的最干净的一份对照证据。
存档 · 2026-06-30
在一台老旧手机上，我找到设置里的「省流加速」二级页，其中一项叫网页预加载，默认开启。关掉之后，此前一直打不开的一个图片站恢复正常加载。这未必是通用解法，但至少说明客户端侧的中间层会影响结果。
观察 · 2026-06-18
这个差异我反复验证了四次：搜索结果页会显示「已屏蔽」，但地址栏里直接输入完整路径能进入。对这类情况的整理，可参照 49图库资料库免费打开网站入口指南 里对入口与拦截面关系的描述，对判断是搜索层的过滤还是解析层的问题很有帮助。
对话 · 2026-06-09
他说完还做了一个动作——拇指在屏幕上从下往上划，像是要调出某个菜单。我后来才明白他指的是把页面强制请求桌面站点，从而绕开站点的移动端判断。关于这个操作本身，我在 qq浏览器如何设置成网页版 里做过详细记录，但这里的重点是：它不能解决 DNS 层的失败。
复盘 · 2026-05-27
域名是朋友的个人博客，用 Let's Encrypt 签发，但漏配了中间证书。桌面 Chrome 和 Safari 有缓存能容忍，而客户端在冷启动时没有缓存，握手失败就被报成「无法访问」。这个案例让我意识到「打不开」有时是个证书完整性问题。
资料 · 2026-05-11
第 96 页的注释写道：链路通、应用层不通，且能 ping 通网关，即为半通。这个老词意外地好用。今天一个网站打不开，往往就是这种「半通」：TCP 能连，但 HTTP 响应被中间人替换成了 302 或空内容。整理这类材料的入口，我放在 496tu.cσm资料库的使用教程 里一并说明。
对比 · 2026-04-23
路由器是 TP-Link 的旧款，我登录后台看到 DNS 被设成两个陌生地址。改回自动获取后，两台 Android 恢复。这个现象说明问题可能出在上游，而手机只是最先暴露它的那台设备。
工具 · 2026-04-02
200 是状态码，裂开是资源路径。站点对移动端返回 HTML 外壳、对桌面端返回另一套资源目录。所以「换 UA」这个动作只改了一部分规则，剩下的要靠资源引用方式自己解析。这也是我在整理相关内容时最常被问到的一类情况，下载香港49图库 页面里也提到过类似的双端资源差异。
疑问 · 2026-03-19
连续七天在 21:50、22:10 两个时间点访问同一域名，22:10 的响应体里出现了 1.2KB 的额外 JS，内容是重定向到充值页。这个时间规律我至今没有合理解释，也不打算用「就是运营商问题」一句带过。
存疑 · 2026-02-14
我做了 20 次对照，清缓存后恢复 10 次，重装后恢复 9 次。接近随机的成功率说明这两步只是碰巧撞上了某个中间状态的改变，而不是根因。写在这里，是为了提醒自己别把这当成结论。
今天我不打算给出一个「一招解决」的方案。因为以我目前的观察，手机qq浏览器打不开网站根本不是一个单一故障。
从 2026 年 2 月到 7 月，我在六台设备、三个运营商网络、四种客户端版本上做了记录。过程中最让我困惑的一点是：同一个 URL，在同一台手机上，隔十分钟就可能有不同表现。有时是白屏，有时是 ERR_CONNECTION_RESET，有时是被替换成一个看起来很像官网的页面，链接却指向陌生的充值站。这种不确定性本身，就是最重要的线索——它说明失败发生在多个不同的层面，而每个层面都有自己的触发条件。我把这些层面粗分成四类：解析层（DNS 被污染或指向异常地址）、传输层（证书链不完整、TLS 握手被中断）、应用层（UA 嗅探、响应体被注入）、客户端层（预加载、缓存、省流代理）。四类之间并不互斥，叠加起来才造就了「同一次点击，两次结果不同」的现场。
举例来说，7 月 21 日老周把 UA 改成含 MQQBrowser 的字符串后，站点返回 403 和一段 23 字节的纯文本。这是他当天下午在办公室里做的第二个实验，第一个实验是直接用 curl 拿首字节，结果是 200 和完整的 HTML。两个实验的差异只有 UA 和 Referer 两个请求头，因此可以断定站点在入口处做了一次客户端判断——这类判断在国内不少资源站上非常常见，它们的理由是「移动端体验」，真实动机却未必如此。这也是为什么单靠清缓存或重启路由器，有时会显得像「玄学」。我们并没有找到原因，只是碰巧让那个判断暂时不再命中。
我的判断：在多数情况下，手机 QQ 浏览器打不开网站的第一责任不在浏览器本身，而在于请求路径上的某个中间节点主动或被动地改变了响应——浏览器只是那个被迫把失败展示出来的界面。
这个判断是有争议的。因为如果中间节点的改变是恒定不变的，桌面浏览器也应该失败。但现实中桌面端往往能打开，说明客户端确实参与其中。我目前能给出的解释是：客户端在开启网页预加载和省流加速时，会经过自家的代理链路取数据，这条链路与桌面直连走的路由不同，因此遇到污染或证书问题时的表现也就不同。6 月 30 日那台旧手机上关掉预加载开关后页面恢复，是支持这个解释的证据之一。但只有一台设备、一次测量，还不足以称之为结论。我在记录里明确标注了「单样本」三个字，提醒自己不要把它写成通用建议。
另一个反复出现的混淆是「打不开」和「打开了但不是我想看的」。后者经常被误报为前者。7 月 28 日那 27 秒白屏之后，我一度以为页面没加载出来，直到把响应体另存为文件，才发现里面是一段完整的运营商标识页，只是被 CSS 的 visibility:hidden 藏起来了。这个发现让我重新审视了此前所有「白屏」的截图。也就是说，一部分「打不开」其实是被打开了一个错误的页面，只是它看起来像什么都没发生。这类情况无法用换 DNS 或换浏览器解决，它需要看响应体和证书链的指纹，而不是看屏幕。
我目前还没有答案的是：为什么运营商注入页只在夜间出现。
连续七天在 21:50 与 22:10 各抓一次响应，22:10 的那次比前者多出约 1.2KB 的脚本，功能是重定向。如果是定时策略，为什么有的夜晚完全没有？我查过运营商公开的技术公告，没有找到对应的说明。于是这个问题只能先挂在那里，和 2003 年那本手册里那句「联通卡，微信能发，网页全白」放在一起。二十多年过去，写法变了，问题类型几乎没变。这也算是我继续做这个站点的理由：把能确认的写清楚，把不能确认的标注出来，让下一个人少走一点弯路。
我是江晚，做过五年运维，现在自己维护这个记录站，主要收整「手机qq浏览器打不开网站」相关的现场证据。
我做这件事的原因很具体：2025 年底帮朋友排查他店里的一台公用手机，那个域名我前后试了三十多次，每次的失败方式都不一样，而网上的答案几乎都是一个模板。我不相信模板，于是开始自己记录。
我的方法很笨：保存响应体、截图证书链、对照不同 DNS、把时间也写进去。写在这里的东西，如果没有验证过三次以上，我会明确说是单样本。这是我对自己的要求，也是这个站唯一的原则。
「链路通、应用层不通，且能 ping 通网关，即为半通。」——《网络故障排查手册》，2003 年版，第 96 页注释。今天下午在城南旧书店翻到，书脊已裂，第 114 页有读者用蓝圆珠笔写下的批注。