最近帮一个本地电商做网络优化，发现他们后台审核订单总卡在“等待同城节点响应”这一步。不是服务器慢，也不是带宽不够，而是审核请求老是绕到几百公里外的中心机房——明明审核员就在杭州，系统却把请求发去了广州的审核集群。
为什么同城审核会“绕路”？
很多中小团队用的还是默认BGP选路策略，只看AS路径最短，不看物理距离。比如杭州IDC出口走的是某运营商骨干网，下一跳自动指向上海汇聚点，再跳一次才到本地审核服务节点。中间多这一跳，延迟从3ms拉到28ms，批量审核100单就多耗2秒以上。
路由层怎么打个“本地结”？
我们没动审核系统代码，只在边缘路由器上加了两条策略：
ip prefix-list LOCAL-REVIEW seq 5 permit 192.168.45.0/24
route-map TO-REVIEW-NODE permit 10
match ip address prefix-list LOCAL-REVIEW
set local-preference 300
set ip next-hop 10.20.1.100其中192.168.45.0/24是审核服务所在的同城VLAN网段，10.20.1.100是本地审核API网关的真实IP。这样所有发往该网段的流量，强制走直连三层交换机，跳过上游运营商链路。
效果立竿见影
调整后，审核接口P95延迟从32ms降到5ms以内，高峰期并发审核吞吐量翻了1.7倍。更关键的是，审核员反馈“点提交没停顿感了”，这种体验提升比跑分数据更实在。
其实同城审核不光是“快”，更是“稳”。上周台风导致上海骨干网抖动，杭州本地审核节点照常运转，订单流没中断一单——因为路由策略早把关键路径钉死在本地环网里了。