同一客户端的基础请求返回成功，进入某个子路径却得到 404，错误正文还可能写着“资源不存在或无权限”。这并不矛盾：两个请求可能匹配不同路由，经过不同的请求规范化逻辑，使用不同上游身份，最后还被代理重新映射状态码。只根据错误文案更换资源名或凭据，往往会同时改变多个变量。本文给出一套只读取、不修改的五层采证方法，先确定失败发生在哪一段，再设计单变量验证。
先画出两条完整链路
不要把“都调用同一个模型或服务”当作同一链路。分别记录：
基础请求：客户端 → 入站 URL → 路由 → 上游 URL → 上游身份 → 响应
子路径请求：客户端 → 入站子路径 → 路由 → 请求改写 → 上游 URL → 上游身份 → 响应
基础请求成功只能证明其中一条路径在某个时刻可用，不能证明子路径存在、请求体兼容或身份权限相同。
第一层：确认客户端实际发送了什么
记录完整客户端版本、请求时间、方法、实际 URL 和不含敏感值的 Header 名称。配置文件中“准备使用”的地址不等于运行进程最终解析出的地址。
重点确认：
- 子路径请求是否真的由当前客户端发出；
- 是否存在旧进程、旧配置目录或环境变量覆盖；
- User-Agent 与实际客户端版本是否一致；
- 失败是否来自当前日志，而不是历史请求。
不要先升级或改配置。第一层的目标是确定正在排查哪一个实际行为。
第二层：检查入站路由和 URL 拼接
常见问题包括：
基础地址末尾的 /v1 被重复或遗漏；
代理只注册了 /responses，没有注册其子路径；
反向代理重写规则丢失路径后缀；
大小写、尾斜杠或方法不匹配；
请求落到默认站点而非 API 服务。
同时记录网关接收到的 URL 与最终上游 URL。只看客户端地址无法判断中间层是否改写正确。
第三层：对比请求规范化前后
兼容层可能删除未知字段、重命名参数、替换资源标识或为子路径构造专用请求。使用同一个 request_id 关联：
入站请求的字段名与类型
规范化后的字段名与类型
最终上游请求的字段名与类型
每次转换采用的规则版本
排障日志优先记录字段是否存在、类型和长度，不记录完整正文。发现字段变化后，再回到代码或配置确认它是否符合当前上游接口。
第四层：确认上游身份和资源映射
错误文本中的“资源不存在或无权限”通常无法单独区分两种情况。检查基础请求与子路径请求是否使用相同的匿名化身份槽位、租户、区域和资源映射。
一条安全的路由记录可以包含：
request_id
route_id
credential_id_or_hash
resource_requested
resource_forwarded
endpoint_forwarded
upstream_status
不要把访问令牌、Cookie 或真实账号标识写进日志。若路由会动态选择身份，需要在测试中固定身份才能比较。
第五层：区分上游错误与代理错误
同时保存上游原始状态和对客户端返回的状态：
upstream_status
upstream_error_type
proxy_status
proxy_error_type
retry_count
final_route
客户端看到的 502 可能是代理包装上游 404、响应解析失败、重试耗尽或连接中断。反过来，404 也可能来自代理本身，根本没有发往上游。
只有确认请求抵达上游并取得原始响应后，才能讨论上游端点或身份权限。
一份最小证据清单
[ ] 客户端与运行时完整版本
[ ] 请求时间、方法和 request_id
[ ] 实际入站 URL 与最终上游 URL
[ ] 请求资源名与最终映射名
[ ] 规范化前后的字段名和类型
[ ] route_id 与匿名凭据标识
[ ] 上游原始状态和错误类别
[ ] 代理返回状态和错误类别
[ ] 重试、回退与最终路由
[ ] 同条件基础请求的结果
采集前先确认日志权限。Authorization、Cookie、会话标识、用户正文和内部文件内容必须删除或脱敏。
设计单变量 A/B
拿到证据后，根据候选层只改变一个变量：
- 验证路由：保持身份和请求体不变，只比较直连与代理；
- 验证身份：保持 URL 和请求体不变，只更换已知权限不同的测试身份；
- 验证规范化：保持上游与身份不变，只启用或跳过转换；
- 验证版本：保持配置和输入不变，只比较两个明确版本。
每组使用无敏感数据的最小请求，并保存原始响应。若无法控制其他变量，结论应写“尚未排除”，不能写成已证明根因。
现象能证明什么
| 现象 | 能够证明 | 不能证明 |
|---|---|---|
| 基础请求成功 | 该条基础链路当时可用 | 子路径和身份也可用 |
| 代理返回 404 | 代理或上游某层返回未找到 | 一定是资源名错误 |
| 代理返回 502 | 代理未能给出有效成功响应 | 一定是网络故障 |
| 升级后恢复 | 版本变化与恢复相关 | 只有某个 Header 起作用 |
| 直连成功、代理失败 | 差异位于两条路径条件中 | 已定位到具体改写代码 |
结论与限制
基础请求成功、子路径返回 404 时，应把两条请求视为独立链路。沿客户端、路由、规范化、上游身份和错误转换逐层记录证据，再做单变量对照，才能避免把模糊错误文本当作根因。
本文不针对某个模型、客户端或代理版本，也不提供通用修复配置。不同接口是否存在子路径以及需要哪些字段，必须依据当前官方文档和实际请求确认；生产凭据和用户数据不应进入排障样本。