文字与生活
302 与 307 为什么不一样？代理排障先看重定向方法
看到 301、302、307 或 308 时，不能只说“网站跳转了”。这些状态码对后续请求方法的处理并不完全相同，登录、订阅下载或接口请求经过代理时，方法是否被保留会直接影响排障结论。
先分清两类跳转
301 和 302 历史上常被客户端用于把 POST 改成 GET；303 明确指向用 GET 获取另一个资源。307 和 308 则要求自动重定向时不要改变原请求方法。浏览器和命令行工具还可能为了兼容旧站点采用不同处理方式，所以不能只凭最终页面正常就推断中间请求完全相同。
先画出重定向链
对你有权访问的公开测试地址，先不跟随跳转：
curl.exe -sS -o NUL `
-w "code=%{response_code} next=%{redirect_url}\n" `
"https://example.com/old-path"
再允许有限次数的跳转，并记录最终地址：
curl.exe -L --max-redirs 5 -sS -o NUL `
-w "code=%{response_code} redirects=%{num_redirects} final=%{url_effective}\n" `
"https://example.com/old-path"
这里使用无敏感信息的 GET 请求做观察。不要把订阅链接、登录令牌或表单内容粘进公开命令记录。
为什么这与机场排障有关
节点只负责传输时，跳转通常由目标站点返回；但代理规则、DNS 或 HTTPS 检查异常可能让某一跳失败。先画出重定向链，再讨论节点，才能知道失败发生在原地址、跳转目标还是方法变化之后。
若只有带表单的请求失败，应由站点自身日志或开发者工具核对方法，不要用反复提交真实表单来试错。机场测评中也不应把一次 302 后成功写成“所有接口都兼容”。
验收标准
记录应包含首个状态码、每一跳的目标域名、跳转次数和最终状态。更换节点后仍在同一跳失败，优先检查目标站点与请求方法；只有失败位置随节点稳定变化，才继续调查线路或分流。
评论