ARTICLE / ai
排障第一课：先怀疑脚手架，再怀疑业务——一次公众号 403 误诊的完整复盘
排障第一课：先怀疑脚手架，再怀疑业务
一次"公众号被风控"误诊的完整复盘：curl 反而是破局点，cookie 差点被全清
2026 年 11 月 3 日上午，收益日报定时任务正常退出，但公众号（微信支付流量主）收入抓取失败，报表沿用前一天旧值。故障卡上当时写的诊断结论是：公众号 cookie 或会话被风控拒绝，去浏览器清 cookie 重新登录即可。
这个结论是错的。真根因在网络分流层——代理配置里一条进程级规则，把整只 Chrome 的流量全部送去了境外出口，而微信公众平台在登录校验之前就按出口地区拒绝访问。清 cookie 不但治不了，还会把仍然有效的登录态一起毁掉。
事后看，这场误诊里最有价值的不是修好它的那两条配置，而是找到真凶的那三步对照实验。它给出一个所有自动化运维都适用的检查顺序：报错先分"出口被拒"还是"真掉登录"，再谈别的。
三条证据，第三条是破局点
现场留了三份证据：
- 用浏览器直接打开公众平台首页，返回的是 HTTP ERROR 403"您未获授权"——不是扫码登录页。落地页有 183KB，不是空响应。
- 从一个还挂着旧登录态的标签页里，带着 cookie 请求已登录接口，同样 403、空响应体。
- 同一台机器上用 curl 直连（不带任何 cookie），返回 200，页面正常。
前两条证据指向"登录态出了问题"，故障卡上的诊断就是这么来的。第三条证据把方向整个倒转：无 cookie 反而能访问，说明问题不在登录态，也不在 IP 段被整体封禁——而是浏览器发的请求和 curl 发的请求走了不同的出口。
“无 cookie 反而 200"不是反常识，它是分流问题的强信号。看到这种对照结果，先查代理，不要先查凭据。
依据本次排障记录中的三条对照证据整理绘制。
根因：一条规则误伤了整个进程
代理配置里有一条进程级规则，把 Chrome 这个应用的所有流量（包括公众平台域名）送去了境外出口：
进程级规则的杀伤面是整只应用。规则一旦命中，该进程访问的所有域名都走同一策略，公众号域名也在内。而公众平台在登录校验之前就按出口地区拒绝，于是返回 403。同一台机器上不走这条规则的抓取通道落到了直连兜底，所以另一个入口一直正常——这正好解释了"同机同网，一个通一个不通”。
修法是在进程规则之前插入按域直连规则（规则顺序即优先级），让微信域优先直连，改完重载配置，在连接面板确认命中策略已变成 DIRECT、命中规则是 DOMAIN-SUFFIX。
验证有一条坑：curl 不走 Chrome 的进程规则，天然绕过故障路径。所以"用 curl 测通了"不能当修复证据，要看实际命中这条路径的那条通道——同一浏览器、同一套 cookie 直接进已登录首页成功，才算数。
更值得记的：误诊是怎么滚起来的
比配置修复更值得复盘的是误诊链。这个抓取脚本的旧版把超时、解析失败、抓取层异常一律兜底成"已登出"，于是从 10 月 14 日到 21 日连续八天误推"需要人工扫码"的故障卡——基础设施故障伪装成了业务状态。这次的 403 又被上一层故障卡写成"cookie 被风控"，再被下一个接手的环节当成事实继承。
三层教训叠在一起：
第一，基础设施故障不得伪装成业务状态。超时是超时、解析失败是解析失败、出口被拒是出口被拒，各自要有自己的失败类别。落地页出现"403 您未获授权"文本，归为出口被拒、查代理分流；只有出现二维码或登录框，才归为真正掉登录。分类错了，后面的处理全错。
第二，故障卡上的诊断结论一旦落卡，就会被后续接手的人当事实继承。落卡前必须做一次对照实验：有无 cookie 各测一次、直连和代理各测一次。这次正是"无 cookie 反而 200"这一格对照结果推翻了之前的全部推论。
第三，同一天这台机器上还同时发生了文件写入权限故障，最初也被误判成凭据问题。一天之内两起"脚手架故障被当成业务故障"，说明它是一种默认倾向，不止发生这一次：排查时人总是先怀疑自己最熟悉的层（账号、会话、业务参数），而真实的变动往往发生在自己没盯着的层（代理分流规则、文件写入权限策略）。所以检查顺序应该反过来——先问"最近什么变了"，再问"业务哪里坏了"。
修复清单与验证口径
给遇到同类问题的读者留一份可核对的清单：
- 排查顺序：先做出口对照（同一 URL，浏览器、curl、换网络各测一次），再查登录态；“无凭据反而能访问"直接指向分流层。
- 检查代理配置时注意规则顺序：进程级规则会覆盖其后的一切，按域例外必须写在它上面。
- 修复验证看命中策略（连接面板里该请求实际走的 policy 和 rule），不看 curl 返回值；最后用真实采集脚本跑一遍，确认拿到的是新鲜数值而不是故障兜底的旧值。
- cookie 一个都不要清。清了会把仍然有效的登录态一起毁掉，而且清完照样 403。
这次事件里没有数据损失：报表旧值只滞后一天，cookie 家底盘点后 23 条全部完好。代价是那一天报表数字不新鲜，以及一次差点执行的错误修复动作。它留下的判断——“报错先分出口被拒还是真掉登录”——已经写进了抓取脚本的故障分类里，下一次同类报错会先走对照实验，而不是先派一张"请重新扫码"的卡。