出口带宽只用了三成却开始超时：出网故障要先看端口、连接跟踪和长连接

周三下午三点，业务群里弹出一条消息：支付回调又开始超时了。运维把出口带宽监控调出来，曲线稳稳地停在三分之一上下，离告警线还差很远，晚高峰也没见它冲上去。业务方在群里追问，是不是该加带宽了。这个问题几乎每隔一段时间就会被问到一次，而答案通常是否定的：这一类白天偶发、晚间自行消失、抓包能看到重传却看不到拥塞的失败，加带宽基本解决不了，因为瓶颈压根不在吞吐那一层。真正的问题在于，大家习惯用"带宽用了多少"这一张图去解释所有出网异常，而出网路径上能先见底的账本并不止这一张。

一批应用节点共用同一个出网地址去访问第三方接口时，出网这条链路上有四样东西会先见底：单个出网地址上的源端口配额、网关上记录地址转换关系的连接跟踪表容量、短连接关闭之后的回收速度、以及长连接被中间设备静默回收的空闲超时。它们耗尽时表现出的现象高度相似，都是建连超时、无响应、偶发且难复现，混在一起看就是同一种故障。但也正因为现象雷同，排查必须有固定顺序，先看表项与端口，再看回收与超时，最后才回到带宽；顺序反了，就会在带宽上反复加码而始终查不到根因。

带宽、连接数与建连成功率的三种曲线：先分清你遇到的是哪一种

出网异常在监控上大致呈现三种不同的形状，分清形状是第一步。第一种是吞吐型：出口流量接近上限，延迟随吞吐单调上升，所有目标地址的响应都变慢，请求不是连不上，而是连上了以后传得慢。第二种是连接数型：吞吐不高，但并发连接数一路上涨，失败集中在建立连接的阶段，表现为握手无响应或者握手超时，而已经建立的连接依然能正常收发。第三种是成功率型：流量和连接数都不突出，成功率却呈间歇性塌陷，几分钟好、几分钟坏，和业务的忙闲没有稳定对应关系。

本文要讨论的是后两种，尤其是第三种。判断依据也很直接：如果失败表现为"连不出去"而不是"传得慢"，那么吞吐大概率不是瓶颈，因为带宽不够的后果是排队，排队的结果是变慢，而不是连不上。另一个判别点是影响面，如果所有第三方目标一起变慢，才更像是链路或者带宽层面的问题；如果只有支付接口失败，短信和地图接口都正常，那么几乎可以肯定瓶颈在某一本更局部的账上，比如这个热门目标地址上的源端口，或者对方对该源地址的限制。

还有一个常被忽略的切分维度：失败发生在哪一个阶段。一次出网请求可以拆成解析、建立连接、安全握手、等待首字节、读取响应体几段，每一段失败指向的资源完全不同。解析阶段失败要去看域名解析与地址选择；建立连接阶段失败要去看端口与表项；已经建立的连接上读写失败，要去看空闲回收与对方侧断连；读取响应体阶段失败才更接近吞吐或者下游处理能力。很多团队把这几段混成一个"接口超时"指标，于是后面所有的排查都失去了方向。把监控按阶段拆开，是本文所有后续动作的前提。

一次出网连接要占用哪几样东西：五元组、源端口、表项

一条连接在网络设备上由五元组标识：源地址、源端口、目的地址、目的端口、传输协议。对内网直接访问外网的节点来说，源地址各不相同，五元组的区分度很充足。但一旦整批节点通过网关做地址转换，对外只呈现一个出网地址，源地址这个字段就对所有节点变成同一个值，能用来区分不同连接的字段就只剩下源端口。这就是共用出网地址这个架构自带的代价，区分度被压缩到了一个 16 位的字段上。

第二样被占用的是网关上的转换表项。网关之所以能把回来的报文送回正确的内网节点，靠的是它记住了"这条连接的外部表现对应内部哪个节点哪个端口"这条映射。这个记住的动作要占用内存里的表，表有容量上限，条目有生命周期。每台做地址转换的设备上，这张表都是整条出网路径上唯一的共享资源，前面所有节点的连接都要在它这里记账。

第三样是业务节点本地的资源：应用层的文件描述符、进程可打开的句柄、内核里对应的套接字结构、以及收发缓冲区。这些往往有进程级的限制，而且限制值和网关那张表完全不相干。

所以同一次看似简单的建连，同时在至少四个地方记账：应用侧的句柄、内核侧的套接字、网关侧的转换表项、出网地址上的源端口。这四本的容量互不相干，扩容其中任何一本都不能缓解另外三本。理解这一点，就能理解为什么"出口带宽只用了三成"和"连不出去"可以同时成立。

源端口配额：单个出网地址的理论上限是怎么被算出来的

端口号字段是 16 位，因此单个地址上的端口编号空间存在明确上限，这个上限可以由编码位数直接推导出来，不需要任何实测数据。但真正能用于出网建连的源端口范围还要再打折：要扣除系统保留的端口区间、本机已经被服务监听占用的端口，以及操作系统为临时端口划定的区间。实际可用范围受操作系统临时端口区间限制，而这个区间的取值随内核版本与发行版差异很大，以你自己的内核版本、发行版与实际拓扑为准，需自行验证。

更关键的一点是，这份配额不是全局平均使用的，而是按"目的地址加目的端口"分堆消耗的。同一个出网地址访问同一个第三方接口的同一个端口时，五元组里三个字段都固定了，能变化的只有源端口，因此这个目标上能同时存在的连接数，直接受临时端口区间大小的限制。反过来，访问不同的目标地址时，五元组不同，同一个源端口是可以复用的。这就解释了一个很常见的现象：整机的出口连接总数并不高，但某一个热门第三方接口在建连时已经开始失败，而别的接口毫无异常。端口不是全局不够，是某一堆先用完了。

时间维度也必须算进去。连接关闭之后，源端口并不会立刻变成可复用状态，处于等待状态的连接仍然占着这个五元组。因此真正的约束并不是"某一瞬间有多少条并发连接"，而是"单位时间内新建了多少条连接"乘以"每条连接从建立到完全释放占用了多久"。建连速率越高、连接存活与残留时间越长，同一时刻被占住的源端口就越多。这也是为什么高频短连接的业务比低频长连接的业务更容易撞到这堵墙。

连接跟踪表见底时的典型表现与观测位置

转换表见底的时候，网关通常不会给任何明确信号，它只是把新连接的第一个报文丢掉，不发差错报文，也不回拒。应用层能感知到的只有一件事：自己发出去的握手包没有回应，直到本地的超时定时器触发。这种静默丢弃正是"偶发超时"这个模糊现象的来源，也是它难以定位的原因，因为从应用侧的视角看，它和下游宕机、链路中断、对端限流没有任何区别。

表现上有几个特征可以辅助判断。新建连接失败，而已经建立的连接继续正常工作；失败是间歇性的，随表项回收的节奏忽好忽坏；失败与业务流量不完全同步，有时业务量回落之后仍然持续一段时间，因为表项的释放有滞后。此外，如果设备日志中出现与表项容量相关的提示，那基本可以直接确认，但提示文字随系统不同而不同，需要查阅你所使用系统的文档，本文中不列举具体字样。

观测位置是最容易犯错的地方。这张表在网关或者做地址转换的那台设备上，不在业务服务器上。在业务机上抓包，看到的永远是"有去无回"，看不到表满。很多排查之所以原地打转，就是因为取证的位置不对，一直在本机翻日志和抓包，而证据在路径中间的转换设备那一侧。要做的观测包括：读取转换表的当前条目数与容量上限、按目的地址聚合条目数看集中度、观察条目数随时间的增长与回收曲线是否贴合失败的时间窗。读取方式随系统不同而不同，本文不给出具体命令。

短连接为什么会把表堆满：TIME_WAIT 与回收节奏

短连接场景在出网方向非常常见：第三方接口用一次一建连的方式调用、对账文件分片拉取、回调通知逐条发送。每一次建连都会在转换表上留下一个条目，而连接关闭之后条目不会立刻消失，它要等到老化时间到期才被回收。于是条目数大致正比于"单位时间的建连次数"乘以"条目从产生到回收的总时长"。当建连速率因为业务高峰而抬升，或者下游响应变慢导致每条连接挂得更久，条目数就会迅速堆到上限。

连接关闭后进入的那段等待状态，存在的意义是保证连接可靠关闭、并避免上一连接的残留报文干扰后续复用同一五元组的新连接。它是协议设计的一部分，不是故障本身。问题出在数量级：当堆积的条目开始挤压可用源端口或者占满转换表时，它才从设计变成故障。由此也引出一个常见误判：单纯看到等待状态的连接数量多就判定为异常，其实数量多本身不等于有问题，只有它开始压制新建连接时才需要处理。

回收节奏由几个配置共同决定：转换表项的老化时长、等待状态的保持时长、以及是否允许复用处于等待状态的连接。这些参数的取值随内核版本与发行版差异显著，本文不提供任何具体取值，也不列举配置路径，以你自己的内核版本、发行版与实际拓扑为准，需自行验证。这里要提醒的是取舍：为了尽快回收而放宽复用条件，理论上会提高旧连接残留报文干扰新连接的风险，是否可接受要结合你的业务协议与对端实现来判断，不能只看到条目数下降这一面。

从处置角度看，短连接的根本问题是"建连次数太多"，因此真正的缓解方向是减少建连次数，而不是把回收调快。回收调快只是在让账本翻页更快，翻页速度提升带来的收益有上限，而建连次数下降带来的收益是乘法级的。这一点会在后面关于连接复用的小节里展开。

长连接被静默回收：中间设备的空闲超时往往比应用侧短

长连接场景同样普遍：消息推送通道、持久连接、连接池里长期持有的空闲连接、大文件的长时间下载。这类连接的问题是另一种：路径上的中间设备，包括网关、转换设备、负载均衡以及上游链路上的其他设备，几乎都对空闲连接维护自己的老化时间。到点之后设备直接删除表项，而且不会通知连接的两端。

后果是两端都以为连接还活着。应用侧的连接状态依然是已建立，连接池也认为这条连接可用，直到某一次请求真正往这条连接上写数据，报文被中间设备丢弃或者得不到回应，应用只能等到自己的超时定时器触发。这类失败有几个很好用的判别特征：失败发生在"已经建立好的连接上的第一次写入"，而不是新建连接的时候；失败与流量无关，常常出现在业务低峰期，因为低峰期连接空闲时间长；抓包时能看到请求发出去了但没有任何回应，连重置报文都没有。

如果失败总是发生在连接池里刚取出来的那条连接第一次被使用时，基本可以往这个方向查。还有一个典型线索是时间规律：空闲多久之后第一次使用必失败，这个间隔在不同网络路径上差别很大，需要在你自己的拓扑上通过保活间隔的对比测试观察出来，需自行验证，因为中间设备的老化时间通常不会对外暴露。

处置方向是让保活间隔短于路径上最短的那一个空闲超时，同时让应用侧的连接空闲超时短于或等于中间设备的老化时间，把"被动发现死连接"变成"主动淘汰即将失效的连接"。但要注意，保活报文本身也会消耗资源，间隔过密会给转换表和下游带来额外负担，这同样是取舍。

定位顺序：先表项、再端口、再回收、最后才轮到带宽

顺序不是习惯问题，而是由四类资源的失效形态决定的。表项和源端口是硬边界，满了就直接丢弃新连接，现象最像"偶发失败"；回收与空闲超时是时间边界，表现为间歇性、与空闲时长相关；带宽是软边界，满了表现为排队变慢而不是连不出去。因此先查硬边界，再查时间边界，最后才回到吞吐，是成本最低的路径。反过来做的代价很具体：先加带宽，现象不变，于是继续加，最后把问题归因于"第三方接口不稳定"，故障留在原地。

执行这个顺序时，先做阶段划分，把失败定位到解析、建连、安全握手、首字节、响应体中的哪一段；再按上表逐项对照观测；只有在前面几项都排除，并且观察到队列堆积、延迟随吞吐单调上升、且所有目标同时变慢时，才把带宽列为嫌疑。还有一个实操建议：观测要落在转换设备上，落在业务机上只能看到现象，看不到原因。团队里如果没人有转换设备的观测权限，那么第一步应该先去解决权限与采集问题，而不是继续在应用侧猜。

连接复用与连接池到底省下了什么，又不能省什么

复用省下的是建连这个动作本身以及它附带的所有开销：一次新的源端口分配、一条新的转换表项、一次握手往返、一次安全握手的协商。也就是说，它降低的是"单位时间内的新建次数"，而新建次数正是短连接把表和端口堆满的直接原因。因此复用对"建连速率型"的瓶颈非常有效，对"并发数型"的瓶颈基本无效。

复用不能省的是并发本身。已经建立的连接依然各占一个五元组、一条转换表项、一个本地描述符，连接数并不会因为放在池里就变少。所以连接池无法突破源端口配额和转换表容量的并发上限，它只是让到达那个上限的速度变慢，并且让单位时间内被反复分配的端口数量下降。指望靠开大连接池去突破端口上限，是常见的误用。

池化还会带来两个副作用。第一个是空闲连接被中间设备静默回收的问题，池越大、空闲连接越多，撞上这个问题的概率越高，因此池必须配备取用前的有效性校验、合理的空闲淘汰与保活机制。第二个是池本身会长期占住表项，池开得过大等于长期占用一部分容量，反而压缩了其他业务的可用空间。池的上限受端口配额、表项容量、下游限流以及自身内存共同约束，不是越大越好，具体规模要按你的目标地址数量与实际并发目标实测确定，需自行验证。

还有一个容易踩的坑：复用必须与对端能力对齐。部分第三方接口会对单条连接上的请求数量、连接持续时间或者并发连接数做出限制，超出之后对端会主动断开。这种情况下，激进的复用不仅不解决问题，还会制造新的断连失败。判断方法是对端文档中是否说明了单连接的限制，以及在日志中观察断开是否呈现规律性，本文不针对任何具体接口给出结论。

多个出网地址怎么分配：按业务、按目标地址，还是按哈希

当瓶颈确实落在单个出网地址的端口配额或者转换表容量上时，增加出网地址是最直接的水平扩展手段，因为它同时把这两本账的上限抬了上去。但"怎么用这些地址"是个独立的决策，三种常见分法各有代价。

按业务分配，例如支付走地址一、短信走地址二、对账走地址三，好处是故障域清晰、定位极快，某个地址上的问题立刻对应到明确的业务线，日志和对方的访问记录也容易对上；代价是利用率不均衡，有的地址长期空闲，有的地址仍然紧张。按目标地址分配，是把压力最大的那个第三方目标单独分一个出网地址，直接缓解热门目标的端口紧张，同时对端如果按源地址做限流，这种方式也能绕开单地址的限额；代价是当目标数量多或者热点目标会变化时，维护成本上升。按哈希分配，是按五元组或者按连接做哈希把流量均匀分散到多个地址上，利用率最均衡，也不需要人工维护映射；代价是可观测性最差，一个业务的流量分散到多个地址，出问题时很难快速回答"这次请求是从哪个地址出去的"。

取舍的原则可以这样记：排查期优先选按业务，稳定期追求效率选按哈希，瓶颈已经明确指向某一个第三方目标时选按目标地址。无论选哪一种，都有两个配套动作必须做：一是对端的访问控制白名单要同步更新，二是应用日志必须记录每一次出网实际使用的源地址，否则后续对账和问题回溯会非常困难。

还有一个常见陷阱：增加了出网地址，但应用仍然使用同一个连接池、同一套超时策略、同一个解析结果，那么收益会非常有限，因为流量根本没有真正分散出去。扩容出网地址要配合分流策略一起改，否则只是买了资源而没有用上。

超时参数要跟下游对齐：否则重试会与原请求叠加

出网方向至少要区分三层超时：建立连接的超时、等待响应的超时（可以再细分为等待首字节与等待整体响应）、以及空闲与保活相关的超时。这三层的取值应当与下游的实际处理时延分布对齐，否则会在两个方向上出错。

第一个方向是超时设得过长。如果应用侧的连接空闲超时远长于路径上中间设备的老化时间，应用就会在一个早已不存在的连接上持续等待，把本可以在秒级发现的问题拖到自己的超时上限才暴露。如果建连超时的取值过大，那么在表项已经见底、请求注定失败的情况下，每一个请求都会占用资源等待到超时，等待期间又会有新的请求进来，资源被持续占住，失败会快速扩散到本来正常的业务。

第二个方向是超时设得过短。如果超时短于下游的实际处理时间，就会在下游还在处理的时候判定失败，然后发起重试，原请求与重试请求同时在下游执行，把一次小故障放大成一次资源冲击。支付、对账这类接口尤其危险，因为重试可能意味着重复的业务动作。

对齐还包括重试的节奏。重试的间隔应当形成递进，而不是在原超时刚到期时立刻重发；总的时间预算要有上限，超过之后直接失败并交给上层处理。本文不给出任何建议数值，具体取值取决于你下游的实际处理时延分布和可接受的等待上限，需要按你的业务实测确定，需自行验证。

重试与幂等：超时后的重发最容易把小故障放大成事故

超时不等于失败，这是出网故障处置中最重要的一条认知。超时只说明在预定时间内没有收到响应，对方可能已经收到、已经处理、甚至已经完成了业务动作，只是响应没有及时回来。对于支付、短信、对账文件这类会产生副作用或者涉及资金与凭据的接口，盲目重发会直接造成重复扣款、重复下发、重复入账。

因此幂等是重试的前提而不是可选项。业务单号去重、幂等键、下游可识别的重复标识，以及最终的对账兜底，这几件事应当在故障发生之前就准备好，而不是在故障中临时补救。没有幂等保证的重试，本质上是在用一个不确定是否重复的动作去赌它只执行一次。

重试策略本身也要有节制：退避而不是立刻重发，退避间隔带随机抖动避免多个节点同时重试形成同步冲击，重试次数设上限，连续失败后熔断一段时间而不是持续尝试。没有退避和熔断的重试，会在下游刚刚恢复的瞬间再压上一轮，把恢复过程打断。

最后要强调重试与出网资源的关系，这是本文主题内的关键点：一次重试要重新走一遍完整的建连流程，重新分配源端口、重新建立转换表项、重新走握手。也就是说，当端口或者表项已经见底时，每一次重试都在给已经饱和的资源再增加一份负担。资源型故障之所以特别容易被放大成雪崩，正是因为它同时具备两个条件：失败是静默的，而默认行为是重发。所以在处置这一类故障时，先确认重试是否在放大问题，往往比先扩容更有效。

解析与失败切换也在这条链路上：别把 DNS 当背景

解析环节经常被当作背景，但它完全有能力制造出和本文描述的现象一模一样的故障。解析失败、解析超时、解析到不可达的地址，在应用层看来都是"连不出去"，而且因为是缓存与多结果轮换在起作用，失败同样呈现间歇性和无规律性。

三个点值得单独检查。第一，解析耗时是否吃掉了超时预算。如果建连超时里包含了等待解析的时间，那么解析变慢会直接表现为建连失败，而实际上连接根本还没开始建立。把解析与建连的超时分开设置与分别统计，能立刻排除这一类干扰。第二，多结果的选取顺序与缓存有效期。第三方接口常返回多个地址，选取顺序、失败后是否切换到下一个地址、缓存到期后是否重新解析，都会影响成功率分布；如果失败重试始终落在同一个解析结果上，那么重试就是无效的。第三，解析发生在哪一侧。如果网关侧存在解析代理或者缓存，应用看到的地址可能与实际出网使用的地址不一致，排查时必须先确认这个事实，否则会照着错误的地址去分析。

配套的观测很简单但常被漏掉：日志中记录每次建连实际使用的目的地址与解析耗时，并按地址维度统计成功率。有了这两项，解析问题与连接问题就能在几分钟内区分开，而不需要反复抓包。

三类处置方案的适用边界

第一类是连接复用与连接池改造，适用于短连接密集、建连速率高、表项与源端口被新建动作堆满的场景。它不适用于下游明确限制单连接请求数或连接时长、或者业务需要按连接做会话保持的场景，也不适用于失败根本发生在已建连接上的情况，那种情况下复用帮不上忙。

第二类是拆分多个出网地址，适用于瓶颈已经确认落在单个地址的端口配额或者转换表容量上，或者对端按源地址做限流的场景。它不适用于对端白名单无法及时同步、业务必须固定出网地址才能被对方识别的场景，也不适用于尚未定位就先扩容的情形，因为扩容会掩盖真实瓶颈并抬高后续定位成本。

第三类是超时与重试策略改造，适用于失败被重试放大、超时设置与下游实际处理时延不匹配的场景。它不适用于下游本身处理能力确实不足的情况，此时改造只是让失败暴露得更快，并不能让请求成功，真正的解在下游或者容量上。三类方案可以叠加，但顺序有讲究：先把超时与重试做对完成止血，再做连接复用降低速率，最后才扩出网地址提升容量。反过来做，容易在根因未明的情况下先付出扩容成本。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。当排查结论指向"出网地址不够"或者"线路质量不稳"时，可用的出网地址数量、带宽与线路类型，就成了需要和资源方逐条确认的内容。

出网异常现场，值班要先问清的六件事

出口带宽监控没打满，是不是就说明带宽肯定没问题？不能直接下结论。带宽不足的典型表现是排队，排队的结果是延迟上升和整体变慢，而且通常影响所有目标；而建连失败、有去无回、间歇性出现，更指向表项、端口与回收。反过来说，带宽图没打满也只是排除了吞吐这一项，不能替代对另外几本账的观测。还需要留意监控的采样粒度，过于粗糙的采样会掩盖短时间内的突发打满。

增加出网地址能解决多少问题？取决于瓶颈是否真的在单个地址的端口配额与表项容量上。如果瓶颈在下游限流、应用在自身连接池上限、或者失败来自已建连接的空闲回收，那么增加地址的收益会很有限。判断方法是先按目的地址做聚合统计，确认压力是否集中在单个地址与单个目标上，再决定是否需要扩地址，最终规模需按你的实际并发目标验证。

连接池开多大合适？池的上限受源端口配额、转换表容量、下游并发限制与自身内存共同约束，不是越大越好。池过小会退回频繁建连的状态，池过大会长期占住表项并增加空闲连接被中间设备回收的概率。合理做法是从实际并发目标出发，配合有效性校验与保活机制逐步调整并观察表项数与失败率，具体数值需在你的环境实测确定。

为什么只在白天高峰出现，晚上压测却复现不了？高峰的特征不只是流量大，还包括建连速率高、下游响应变慢导致连接存活时间变长，这两个因素相乘才会把表项与端口堆满。如果压测只压吞吐而不压建连速率，或者压测时长不足以让条目堆积到上限，就复现不了。另外高峰时下游处理变慢会改变超时的相对关系，也会引入新的失败模式。

出网方向的解析要不要单独拆出来看？要。解析失败、解析超时、解析到不可达地址，在应用侧的表现与建连超时完全一致，而且因为缓存和多结果轮换，同样呈现间歇性。建议把解析耗时与建连耗时分开统计和分别设限，并在日志里记录每次建连实际使用的目的地址，这样才能在几分钟内区分解析问题和连接问题。

中间设备的空闲超时我从哪里知道？通常拿不到，因为中间设备一般不会向两端暴露自己的老化时间配置。可行的办法是在你自己的拓扑上用不同的保活间隔做对比测试，观察在哪一个间隔之下空闲连接不再失效，从而逼近路径上的最短老化时间。这个值在不同网络路径上差别很大，需自行验证，不能照搬其他环境的经验值。

能不能靠调大某个内核参数一次性解决？不建议。参数调整能改变的是某一本账的容量或翻页速度，如果没先确认是哪一本账见底，调整很可能只是把表象推迟，同时引入副作用，例如放宽复用条件带来的报文串扰风险。正确顺序是先定位到具体资源，再谈参数，且任何调整都要以你自己的内核版本、发行版与实际拓扑为准，需自行验证。

哪些判断必须你自己在现场确认

本文能给出的是排查顺序和资源边界的框架，但下面这些判断必须在你自己的环境里确认，任何人无法替你完成：转换表的容量上限与当前条目数，以及读取它们的方式；本机临时端口区间的实际取值范围；等待状态的保持时长与是否允许复用的当前策略；路径上中间设备的实际空闲老化时间；下游接口的实际处理时延分布与它对单连接、单源地址的限制；失败在解析、建连、握手、首字节、响应体各阶段的分布比例；以及每一次出网请求实际使用的源地址与目的地址是否已被完整记录。

需要明确划界的是：本文只讲排查顺序与资源边界，不提供任何具体内核参数取值，不讨论具体品牌防火墙或者网关设备的配置命令，不给出任何性能数值或百分比。所有涉及系统参数的地方，一律以你自己的内核版本、发行版与实际拓扑为准，需自行验证。本文中出现的任何架构描述都属于通用部署思路示例，不指向任何具体客户，也不构成性能承诺。

关于出网故障排查顺序的几条判断线

第一条，失败发生的阶段决定排查方向：解析阶段看解析与地址选择，建连阶段看端口与表项，已建连接上的读写失败看空闲回收与对端断连，读取响应阶段才看吞吐与下游处理能力。

第二条，形态决定优先级：偶发且无规律的失败优先查表项、端口与回收；持续且随流量增长的变慢才优先查带宽。把这两类弄反，是最常见的无效排查。

第三条，影响面决定位置：只有部分目标失败，查该目标上的源端口与对端限流；所有目标一起变慢，查链路与带宽；只有某一个业务的流量失败，查它的连接池与超时设置。

第四条，时间规律决定性质：低峰期反而更容易失败，指向空闲回收；高峰才失败且回落之后仍持续一段时间，指向条目堆积；与流量完全同步的失败，才更接近吞吐。

第五条，处置顺序是止血、降速率、提容量：先修超时与重试，再做连接复用，最后才扩出网地址。顺序颠倒会增加成本并掩盖根因。

第六条，任何资源型故障都要先检查重试是否在放大它。静默失败加重发，是这一类故障从小问题演变成事故的主要机制。

出网排查的技术口径与来源说明

本文讨论的五元组、地址转换表项、连接关闭后的等待状态、中间设备的空闲老化等概念，均属于通用的公开网络协议与操作系统知识，不指向任何具体产品实现，也未引用任何厂商设备的规格说明。文中所有关于现象形态与排查顺序的描述，都是基于这些通用原理的推导，而不是基于某一次具体环境的测量结果。

本文未引用任何实测数据、延迟数值、丢包数据或者性能跑分，未给出任何具体内核默认值、配置路径与配置命令，未给出任何性能数值或百分比，也未涉及具体数据库产品或具体厂商设备的配置细节。涉及系统参数与规模的地方，均以你自己的内核版本、发行版与实际拓扑为准，需自行验证。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。具体的机型、带宽、出网地址数量与报价，仍要以官方实时信息或咨询确认为准。

如果你的出网故障已经按本文的顺序定位到具体资源，接下来要做的就是在自己的环境里补齐那几项观测，并把结论用自己的数据再验证一遍。