6 月 11 日那台 ThinkPad X230 上,Chrome 126 把 49图库 官网 的入口页重定向了四次
用 `chrome://net-export` 抓了 47 秒的网络日志,302 链条里夹着一个 200 的中间页,肉眼根本看不出来。这篇把日志逐行拆开讲。
2026-06-11这不是一个比喻。是一条真实存在的页面地址,在 Chromium 内核里转了三圈又弹回原页,在某个国产壳里直接跳去应用商店。我把这一晚的录屏、报错和 URL 参数全部存了档,写成这一篇。「帮我打开浏览器」这个站名,本身就是一句抱怨。
用 `chrome://net-export` 抓了 47 秒的网络日志,302 链条里夹着一个 200 的中间页,肉眼根本看不出来。这篇把日志逐行拆开讲。
2026-06-11把 UA 改成 iOS Safari 之后,页面结构变了但脚本没变,结果是个「四不像」——布局是移动端,交互是桌面端。我保留了完整截图。
2026-06-10它在搜索建议里出现的频率,比我预想的高出三倍。我把 2025 年 12 月到 2026 年 5 月的相关查询词做了一张趋势表,看完有点闷。
2026-06-09答案不复杂:服务端只看 UA 里的 Mobile 关键字。但复杂的是,它会在你不注意的时候把你的会话 cookie 清掉。
2026-06-08第三次我干脆开了抓包,发现是 302 到了 CDN 的一个空壳页。小周在微信里回我一句:「对吧,我也这样。」
2026-06-04降级花了 4 小时 20 分,复现用了 12 秒。值不值?我觉得值,但这篇文章写得很不客气。
2026-06-03顺序很重要:先看 DNS,再看 301/302,最后才怀疑内核。反过来查的人,往往白折腾半小时。
2026-06-02先把场景摆清楚。2026 年 6 月 11 日,周四,晚上九点四十,我坐在书桌前,用那台 2013 年产、被我加装到 16GB 内存的 ThinkPad X230,打开 Chrome 126,准备核对一份周四该发的稿子里的外链。其中一条指向 49图库 官网 的地址,在地址栏里回车之后,页面停了大约 1.8 秒,然后刷新了一次,回到我出发的地方——精确地说,是跳回了我上一秒还停留的那个页面。我又点了一次,这次它没刷新,而是弹出了一个我此前从没见过的中间页,白底,两行蓝字,右上角有个关闭按钮,我还没来得及看清那两行字写的是什么,页面就自己往前跳了。
我盯着屏幕愣了大概三秒。然后我打开了抓包工具。
这件事之所以后来被写成一篇长文,不是因为它罕见,恰恰是因为它太常见。用 `chrome://net-export` 录了 47 秒的网络日志之后,我在里面数出了四个 3xx 状态码,链条是 302 → 302 → 307 → 302,中间夹着一个状态码 200 的中间页——就是那个白底蓝字的页面——它本身并不渲染任何可见内容,只负责在 DOMContentLoaded 之后立刻执行 `window.location.replace`,把你的 tab 会话,连同 referrer 一起,送到下一个地址。这种做法在技术上完全合法,在体验上则接近一种欺瞒。我在日志里给它单独标了一行注释,写的是:「用户看不见的 200,比看得见的 404 更麻烦。」
抓到这一步,问题已经不再是「网页打不开」,而是「网页假装打开了」。
我把这条链路在六个浏览器里分别走了一遍,记录如下,时间精确到秒,环境是同一台机器、同一个网络、同一份 DNS 缓存:Chrome 126 平均 1.8 秒后跳回原页,Firefox 128 卡在中间页 4 秒左右然后白屏,Edge 126 直接把页面拦下来,提示「此站点已重定向多次」;一个基于 Chromium 的国产壳浏览器在 0.6 秒内弹出了应用商店的下载引导,而我根本没有安装那个应用;另外两个浏览器,一个成功进了目标页,另一个在第二次尝试时进了。也就是说,同一个 URL,六次点击,成功率是二比六。我在笔记本上用红笔写了一句:「这不是概率问题,这是设计问题。」
中间页那一环,是我认为最值得掰开讲的地方。它不报错,不弹窗拦住你,也不留下任何可见的历史记录痕迹——你按后退键,回到的是更早的那个页面,而不是它自己。它静静地存在 200 到 900 毫秒,完成一次 referrer 清洗、一次 UA 检查、一次 cookie 写入,然后消失。我查到其中一个中间页引用了 `navigator.userAgent` 里的三个字段做判断,并且用 `setTimeout` 兜底,如果 1.2 秒内没有跳转成功,就换一个地址再跳。这套逻辑写在压缩后的脚本里,混淆得不算深,我花了二十分钟就解出来了。解出来的那一刻,我承认我有点生气——不是对技术,是对这种「把用户的等待当成可以任意填充的缓冲」的习惯。
顺便说一句,那个中间页的脚本,还顺手清掉了我的 localStorage。
关于「49719浏览器打开url四不像」这件事,我在另一篇文章里单独写过,这里只补一个数据:我手动把 UA 改成 iOS Safari 之后,页面确实变成了移动端的布局,但脚本仍然是桌面端的逻辑,于是出现了「布局是手机、交互是电脑」的四不像状态,点击按钮没反应,长按也没有上下文菜单。这不是浏览器的问题,是页面在服务端和客户端各做了一半判断,谁也没做全。我在那篇文章里给这现象起了个名字,叫「半响应式陷阱」,目前还没看到别人用同样的说法,但我坚持这么叫。
我必须把这句话说重一点,因为我知道它会得罪人:一个页面如果检测到桌面 UA 就把你导向应用商店、或者在中间页里塞一个下载引导,它本质上不是在做「兼容」,而是在做「筛选」——它筛掉了不愿意装 App 的人,而这些人恰恰是内容最忠实的读者。我见过太多这样的情况,2025 年 12 月到 2026 年 5 月这半年里,我记录在案的十七个类似页面中,有十一个在移动端正常、在桌面端全部或部分失效。这个比例不是巧合。所以我每周更新这个站,就是想把这些「看起来正常、其实打不开」的案例一个个钉在案板上,标上时间、浏览器版本和重定向次数,让后来的人查的时候,至少能查到一份具体的记录,而不是一句轻飘飘的「请更换浏览器」。
这也解释了为什么这个站叫「帮我打开浏览器」——它是我对这件事唯一的、持续的抗议方式。
最后说一个我上周做的小实验,作为这篇的收尾。我写了一个只有 34 行的本地脚本,对一个给定的链接连续请求 30 次,记录每次最终落地的 URL 和总耗时,不模拟任何 UA,不做任何干预。三十次里,落在目标页的有 21 次,落在中间页的有 6 次,落在原页的有 3 次。我把这张表打印出来贴在显示器边上,旁边用铅笔写了一行小字:「所以你说的『打不开』,其实有 21 次是打开了的,只是你没意识到你被送回原点了。」这行字我每次抬头都能看见,它提醒我,写这个站的时候不能只凭情绪,得凭数据——哪怕情绪本身,也是从数据里长出来的。
下周要写的选题已经定了:中间页里那三个 UA 字段,到底分别对应哪一类跳转分支。样本还在攒,攒够 20 个就发。
我叫江晚,在做一份和浏览器兼容、URL 重定向有关的技术记录工作,白天上班,晚上写这个站。这个站没有编辑、没有排期、没有商务,所有文字都是我一个人在书桌前敲出来的,错字也是我自己的。
我为什么做这个站?因为我受够了一句「换个浏览器试试」。这句话被用来终结讨论的次数,比它真正解决问题的时候多得多。我想把每一次「换个浏览器」背后的具体原因拆开:是哪一次重定向、哪一个 UA 判断、哪一个被悄悄清掉的存储。拆开之后,你至少知道自己在跟什么较劲。
我的写作偏好比较固执——喜欢长段落,喜欢把一件事从头讲到尾,喜欢在文里引具体的时间、版本号、状态码,因为「大概是那次」对我来说等于没写。如果你也讨厌被中间页糊弄,那这个站可能合你的口味。更新固定在一周一次,通常周四晚,写不完就周五,写砸了就删掉重写。
这个站不接受投稿,也不打算变现。如果你在某个链接上卡住了,想让我测一次,可以在站内任意文章的评论区留言,我看到了会尽量回。回不了的,说明我也没有更好的答案,那就一起卡着。
“重定向不是错误,但连续四次重定向,就是一次没有被告知的迁移。”—— 出自《HTTP 权威指南》(Gourley & Totty 著,O'Reilly,2002 年版)第 12 章「重定向与缓存」一节,原文为作者对 3xx 状态码链的评注译文