出口归属核对有三种做法：从设备侧查、从业务侧查、从中间转发环节查。前两种都只能看到单点结果，只有第三种能看到全局的实际走向。ROS 软路由上的流量日志正好承担这个角色，代理IP线路在这台设备上的真实表现，比任何一侧的自述都可靠。本文按四个环节讲怎么用流量日志核对代理IP线路，以及日志读不懂时最容易犯的两个错。
环节一：日志里有什么字段是核对需要的
核对需要的字段其实只有四个：内网来源、实际外发地址、协议端口、连接时间。带这几个字段的信息才能同时回答谁在用、走哪里、什么时候。ROS 的会话列表与日志项里都能看到远端地址，这是与线路比对的关键一项。
要提醒的是，连接记录数量很大，几十台设备持续运行时短时间就能攒上千条。因此代理IP线路的核对要用日志看走向，不是留全部历史。保留时长按需要设，超过就清，不要指望以后翻一年前的记录查问题。
环节二：核对的具体做法
第一步是把登记值取出来：台账里写明的接入地址，以及预期出口归属。第二步从会话列表里取当前活跃连接的实际远端地址，与登记的接入地址比对。这一步查的是流量是否真的接到了指定线路上，最常见的偏差是配置写了但实际仍从原始出口出去，在日志里表现为远端地址是业务目标本身，而不是线路入口。
第三步按内网来源做分组统计，看每个设备或者分组贡献的连接数量，与预期用途对照。异常来源在这里最容易暴露：某个本该走 A 线的分组连接全落在 B 线上，或者出现台账里没有的来源地址。第四步查时间维度，把连接数量按小时统计，核对是否与业务排期一致。
四步里第三步价值最高，因为它能发现配置以外的行为。归属核对如果只做前两步，等于只确认了接上了，没有确认接对了谁。
环节三：两个容易读错日志的地方
一是地址形式带来的混淆。同一线路可能有多条接入地址，登记的是主地址，实际连接可能落在备用地址上，两者都算正常，但按字面比对会判成异常。核对时应当按归属范围比对，而不是按单个地址比对。这要求台账里写的不是某个地址，而是允许的地址段或者标识集合。
二是转发环节造成的地址替换。经过软路由之后，日志里看到的远端地址与设备侧看到的并不完全相同，某些场景下会多绕一段。读日志时如果不清楚这一点，会误以为流量走错了线路。判断办法是拿同一条连接在设备侧与软路由侧各看一次，比对两者是否指向同一线路，比对结果一致就说明只是记录视角不同。
这两处的共同教训是：日志读不懂多半不是日志不够详细，而是没有把拓扑先画清楚。批量环境里建议维护一张简明的走向图，标出各段谁负责、地址在哪一段替换，核对时照着图看日志，效率会高很多。
环节四：把核对做成周期性动作
一次性核对只能确认当下。有长期价值的是把四步核对做成固定周期，并与两个动作绑定：每次线路调整后必做一次，作为变更收口；每月固定做一次，覆盖没有变更的存量线路。前者的意义更大，因为绝大多数偏差出在变更之后而不是运行过程中。
核对结果按线路留一份记录：连接来源数量、实际远端地址范围、与登记相符比例、发现的异常来源数。四个字段固定写下来，几个月后就能看出哪些线路需要重新核对配置。线路在长期管理中最怕的是没人说得清现在谁在用，一份持续积累的核对记录正好解决这件事。日志的价值不在于记录多少，而在于能否随时回答归属问题。
问：日志要保留多久才够用？
按核对周期定，覆盖到下一次核对之前即可，通常两周足够。留太久的连接记录除了占用空间没有额外价值，出问题时能用的仍是最近一段。
问：能不能只用日志做归属核对，不做设备侧查询？
不能。日志能看到连接去了哪里，但看不到业务实际感受到的出口。两者结合才是完整核对：日志看走向，设备查询看归属结果。