请求出了问题，第一件事通常是翻日志。可代理日志里那些字段，每一列到底代表什么？为什么同一段时间里，有的字段一直有值、有的经常空白？把这些字段认全，日志就不再是一堆看不懂的字符，而是一份能倒推问题的记录。
基础字段记的是“这次连接是谁”
每条连接记录通常包含：建立时间与结束时间、来源地址和端口、目标域名与端口、出口地址。这四项拼起来就是一条连接的时间线——什么时候建的、从哪来、要去哪、从哪个出口出去。排查方向性的问题，比如请求根本没发出去、出口不对、连接一建立就失败，看这一组字段就够了。
出口地址这一项尤其值得留意：它记录的是请求实际从哪条出口发出，与业务侧的账号、归属地信息放在一起，就能还原“哪个出口对应了哪次业务动作”。遇到需要回溯的场景，这一列就是最直接的索引。
业务字段记的是“这次请求干了什么”
更细的日志会记录请求方法与路径、响应状态码、传输字节数、处理耗时。状态码能看出请求是被正常处理还是被拒绝；字节数能核对流量和计费是否对得上；耗时能定位慢是发生在代理这一跳还是后面。这一组字段适合排查“连接是通的，但结果不对”的情况。
- 先按时间对齐：把代理日志与业务日志的时钟校准，同一事件在两边各取一次时间戳再对照
- 再按字段分层：方向性错误看连接字段，结果性错误看业务字段，不要混着看
- 盯住异常值：状态码不是 2 开头、耗时突增、字节数为 0 的记录优先处理
- 保留样本：问题记录连同前后几条一起留存，比单条记录更有判断价值
字段为什么会空白
不是每条记录都填满所有字段。连接没走到转发阶段，业务字段自然为空；连接被中途切断，结束时间可能缺失；部分代理为了省空间只记关键字段。空白本身也是信号——它往往说明请求断在了哪一个阶段，比乱糟糟的报错更值得注意。
日志粒度可以调，但记哪些字段通常由服务商决定。对使用者来说，能拿到的时间、目标、状态码、字节数这几项，已经足够覆盖绝大多数排查场景。
需要提醒的是，日志的价值在于长期留存与定期回看，而不是只在出问题时才翻——连续的记录能看出趋势，单次的快照只能说明当下。
夜里任务批量失败，打开日志按时间排序，发现状态码一列全是超时、目标域名却各不相同，基本就能锁定问题出在出口一侧而不是目标站本身。字段认全之后，这种判断几秒钟就能完成；而代理IP链路的健康状态，也正是在一次次这样的核对里被看清的。