深信服AD出站链路排错指南：智能路由与DNS代理实战

简介：资源为深信服AD智能路由常见问题排错指导演示文稿，面向企业网络运维、设备调试与技术支持人员，解决智能路由不生效、上网时快时慢且DNS解析不稳定、DNS代理不生效等典型故障。内容按问题现象分模块梳理，给出从智能路由配置核对、链路状态确认、出站会话保持子网掩码调整，到路由测试工具使用、DNS监听地址与服务器列表校验、DNS服务器在线状态检查的完整排查路径，并补充了DNS代理优先级高于智能路由、线路繁忙保护比例设置等关键细节。同时剖析了常见误区，如ICMP连接跟踪导致的探活误判、轮询调度引发跨运营商DNS解析失败等，帮助读者避开经验性陷阱。包体为单份演示文稿，大小608KB，共1个文件，便于培训或现场快速查阅。已有135人学习下载，适合需要快速定位深信服AD设备出站选路与DNS代理问题的工程师对照参考。

1. 出站链路排错为什么难：三条线索要分开看

深信服AD做多WAN出站负载时，报障最多的是三类问题：智能路由不生效、上网时快时慢、DNS有时解析不到。它们经常一起出现但根因完全不同，混在一起查最容易绕进死胡同。排错核心是把DNS请求和HTTP数据出站拆成两条路径分别验证：启用了DNS代理时，UDP 53端口数据包根本不走智能路由，而是由DNS代理模块选路；只有没启用DNS代理时，DNS请求才参与智能路由匹配。这个优先级决定了排查顺序。另一个常见误区是长ping公网IP验证链路切换，拔掉一条WAN线后ping不通就判断故障，实际上ICMP连接跟踪保持30秒，HTTP访问是正常的。下文按智能路由、出站负载、DNS代理三条线拆排查步骤，每步给出配置核查点和验证方法，适合刚接手多出口链路、或正被链路负载问题折腾的网络运维工程师。

2. 智能路由不生效：匹配规则、会话保持掩码与链路状态排查

智能路由不生效的报障在双运营商或多运营商出口场景下非常常见。所谓不生效，通常指配置了明确的选路规则，但实际流量没有按规则走。这类问题的定位逻辑其实很固定：先看配置本身、再看链路状态、然后看出站会话保持的掩码设置，最后用路由测试验证。按这个顺序走一遍，多数场景能在十分钟内定位。下面拆开讲每一个环节为什么会影响选路，以及检查时该看哪些数值。

2.1 智能路由的匹配机制：自上而下、命中即停

智能路由的匹配机制是自上而下逐条执行的，流量只要命中第一条规则就不再往下匹配。这个设计让规则顺序成为配置中的头等大事。常见的问题是规则顺序和预期不符，例如把default策略放在中间，或者把目标ISP写得太宽，导致下面的细粒度规则永远没有机会命中。检查配置时，先把规则列表从上到下过一遍，确认每条规则的源地址、目标ISP、出站接口和启用状态都符合预期，再谈其他原因。

匹配机制的另一个关键点是ISP地址段的覆盖。智能路由的目标IP通常按运营商ISP网段归类，AD内置的ISP地址库会周期性更新，但更新滞后或自定义网段缺失都会造成目标IP不在地址段内。流量匹配不到规则时，会落进default策略，被默认的负载算法分散到多条线路，从现象上看就是智能路由不生效。所以配置核查不只是看规则的源和目的，还要确认目标IP是否真正存在于ISP地址段中。

另外要留意规则的启用状态和出站接口的物理状态。规则保存了但没启用，或者绑定的出站接口被业务改动时禁用，流量同样不会按预期走。这种低级问题在变更频繁的现场环境里出现概率不低，检查成本也最低。

2.2 链路状态：离线与繁忙是两个隐藏变量

配置正确仍然不生效时，下一步查链路状态。在【系统概况】-【链路状态】页面可以看到每条外网线路的实时状态，包括在线或离线、当前带宽占用率、丢包率、监视器探测结果。智能路由选路时会跳过状态为离线的线路，如果某条规则绑定的线路恰好离线，这条规则就形同虚设，流量会被转移到其他线路或default策略。

链路离线的直接原因是链路监视器探测失败。AD会周期性地通过监视地址探测线路连通性，连续失败达到阈值就把线路标记为离线。监视地址的稳定性直接影响线路状态的判定——如果监视地址本身经常丢包，线路就会被误判离线，出现线路明明通着但智能路由不选它的现象。第3章会专门讲监视器调优，这里先记住：链路状态页里线路频繁在在线和离线之间跳动，优先怀疑监视地址。

线路繁忙是另一个隐蔽变量。启用线路繁忙保护后，当线路的带宽占用超过设定的比例，这条线路会被临时排除出调度池。此时即使智能路由规则正常，流量也进不了这条线路，表现同样是智能路由不生效。排查时要看链路状态页的实时带宽利用率，对比繁忙保护比例，确认线路是否处于繁忙被排除的状态。

2.3 出站会话保持：子网掩码过大会覆盖智能路由

出站高级配置里的会话保持参数，是智能路由排错里最容易被忽略的一个环节。会话保持的本意是让同一个源IP的多次连接始终走同一条出站线路，避免因为频繁换线导致应用登录态失效或TCP连接重置。这个功能本身没问题，出问题的是子网掩码的设置。

会话保持子网掩码决定同一源的判定范围。255.255.255.255表示只对单一源IP做会话保持；255.255.255.0表示整个C段源IP的会话都会被保持到同一条线路；如果设成255.255.0.0，一个B段内的所有源IP都被锁在同一条线路上。掩码越大，被锁定的源IP范围越大，智能路由的负载均衡空间就越小。当内网规模稍大时，这种配置会让大部分流量挤在一条线路上，另一条线路空转，用户感知就是智能路由完全没有生效。

2.3.1 掩码与内网终端规模的匹配

终端总数在100以下时直接使用255.255.255.255，让每个终端独立选路；终端较多且内网按部门划分VLAN时，可以按VLAN网段设置掩码，比如每个VLAN一个C段就用255.255.255.0，但不要跨C段设置。修改完后，已有会话不会立刻重新选路，要等待会话老化或手动清除会话表，否则测试结果仍然是旧线路。

2.4 路由测试：验证选路结果的可靠工具

排查过程的最后一步是验证。AD在【智能路由】-【路由测试】中提供了专门的测试工具，可以指定源IP、目标IP、协议和端口，模拟一条流量并展示它命中的规则、实际选用的线路。这个工具的价值在于绕过真实流量的干扰，直接看配置层面的选路结果。

使用路由测试时要注意，它展示的是按当前配置应该走哪条线路，而不是真实流量正在走哪条线路。两者不一致的情况通常有两个原因：一是会话保持把源IP锁到了已有会话所在的线路上；二是链路状态导致规则被跳过。所以路由测试结果正常，不能完全证明线上流量正常，还需要结合设备的会话表确认实际转发路径。

2.5 不要用长ping验证链路切换：ICMP连接跟踪保持30秒

现场还有一个高频误判：用PC长ping公网IP来验证链路切换是否生效，拔掉一条WAN口线路后看到ping不通，就断定故障没有解决。实际上这是ICMP连接跟踪保持机制造成的假象。AD会为ICMP流量建立连接跟踪表项，默认保持30秒左右。拔线后的30秒内，ICMP报文仍然按旧的表项转发到已断开的线路，表现为报文丢失；30秒后表项老化重新选路，ping才会恢复。

判断链路切换是否正常，更可靠的手段是用HTTP请求验证：

# 每3秒发起一次HTTP请求，观察拔线前后的响应码与耗时变化 for i in $(seq 1 20); do curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" http://www.example.com/ || echo "failed" sleep 3 done

脚本逻辑：循环20次，每次用curl发起HTTP GET请求，-s静默模式去掉进度输出，-o /dev/null丢弃响应体，-w输出自定义结果，%{http_code}是HTTP状态码，%{time_total}是本次请求的总耗时，|| echo "failed"负责捕获连接失败的情况。拔线后如果状态码保持200且耗时只有短暂跳变，说明选路切换正常；如果出现连续的失败或超时，再回到链路状态和监视器配置里排查。

3. 上网时快时慢与DNS解析失败：繁忙保护、ISP地址段和链路监视器

上网时快时慢和DNS偶尔解析不到，是出站链路负载最磨人的两个现象。它们不是独立故障，而是同一套选路机制在不同环节的体现。访问一个网页要经历DNS解析和HTTP请求两个阶段，这两个阶段走的路径不同：启用了DNS代理时，UDP 53的DNS报文由DNS代理模块选路，不参与智能路由；没启用DNS代理时，DNS报文才走智能路由。所以排查必须分两步：先确认DNS解析是否正常，再确认HTTP数据出站是否正常。本节从三个最常出问题的变量展开。

3.1 出站链路负载的两个阶段：DNS请求与HTTP数据分离排查

判断DNS请求是否正常，可以从客户端直接发解析请求或抓包观察；判断HTTP数据是否正常，则看网页访问的响应速度和失败率。两个阶段分别验证的好处是能快速缩小范围——如果DNS解析正常但网页慢，问题在出站链路负载；如果DNS解析本身就慢或失败，问题在DNS代理配置。

需要反复强调的是优先级关系：DNS代理的优先级高于智能路由。这意味着一旦启用了DNS代理，无论智能路由规则怎么配置，DNS请求都不会按智能路由选路。很多现场在智能路由上反复调整规则试图解决DNS慢的问题，方向从一开始就是错的。先确认DNS代理是否启用，再决定从哪个模块下手。

3.2 线路繁忙保护：时快时慢的头号根因

时快时慢最典型的原因是线路繁忙保护触发，导致智能路由规则被绕开。AD的链路负载默认采用加权最小流量算法，新会话会选择当前流量占比最小的线路。正常情况下这个算法能把负载均衡到两条线路上。但如果配置了线路繁忙保护，当某条线路的带宽占用率超过设定比例，AD会把该线路临时排除出调度池，所有新流量只能走剩下的线路，或者落入default策略。

default策略通常使用加权最小流量算法在新会话之间选路，结果就是用户的每个新连接都可能走不同运营商线路。电信线路和联通线路到同一目标网站的延迟差异明显，网页元素加载一会儿走电信、一会儿走联通，整体表现就是时快时慢。解决方法是把繁忙保护比例改成99%，让繁忙保护几乎不触发；新配置设备时建议直接就设成99%。如果只有1条电信和1条联通线路，两条线路互为唯一备份，排除任何一条都等于把流量全部压到另一条，此时应该直接禁用繁忙保护。这个配置动作本身没有难度，难的是现场往往不敢动这个参数，担心改成99%后线路拥塞无人兜底，实际上双出口场景下99%的触发阈值已经足够覆盖绝大多数拥塞场景。

3.3 目标IP不在ISP地址段：智能路由规则落空的表现

第二个变量是目标IP不在ISP地址段内。智能路由按ISP网段匹配目标，但AD内置的ISP地址库不可能覆盖所有IP。CDN节点、云厂商的弹性IP、海外节点，都可能落在地址库之外。这些流量匹配不到具体规则，直接进入default策略，被负载算法分配到任意线路。

表现同样是时快时慢，但定位方法不同：用路由测试把实际访问的目标IP填进去，看是否命中规则。如果命中不了，把目标IP或对应的网段手工加到ISP地址段里，智能路由就能按运营商归属选取线路。对于域名访问的场景，可以先解析出域名当前的IP，再决定是否要维护一条自定义ISP规则。常见做法是优先处理那些访问量大、且明显归属单一运营商的业务域名。

3.4 链路监视器设置不当：线路离线的隐性因素

链路监视器负责探测每条外网线路的健康状态，它的配置质量直接决定链路状态页的在线或离线判定。监视地址选择不佳时，线路会被误判离线并导致选路抖动，用户侧感受到的同样是网速忽快忽慢。常见问题包括：监视地址选在某个小网站，对方限流或宕机后AD把线路标记离线；监视地址和业务走同一条物理链路，链路拥塞时监视报文和业务报文互相挤占。

# 评估监视地址自身稳定性的探测命令（在AD内网侧发起） ping -c 60 -i 5 223.5.5.5 | grep -E "time=|loss" | awk '{print strftime("%H:%M:%S"), $0}'

命令逻辑：ping -c 60发60个探测包，-i 5每5秒一次，总共5分钟，grep -E "time=|loss"筛出响应时间和丢包统计，awk给每行加上时间戳。如果监视地址本身丢包率超过1%或响应时间波动大，就说明这个地址不适合做监视目标。更换监视地址后，AD会在下个探测周期自动恢复判定。我一般会选两个不同运营商的稳定公共地址作监视目标，避免单一地址抖动导致误判。

监视器的探测间隔和失败次数也会影响判定速度。探测间隔太短可能被目标设备限流，间隔太长则离线切换偏慢。失败次数决定线路何时被判离线，设置过大时线路已经断了但AD还在继续转发流量。这两个参数一般保持默认，除非遇到频繁误切换的场景才去调整。

3.5 DNS解析不到的排查顺序：调度策略与服务器状态

DNS解析不到的问题，在启用DNS代理的场景下按两条路径排查。第一条路径是调度策略导致的跨运营商解析：DNS代理的调度策略如果是轮询或加权轮询，访问电信站点时DNS请求可能被分配到联通的DNS服务器，而联通DNS未必能解析电信域名，结果就是解析失败或返回错误结果。这个场景虽然不多见，但确实是轮询策略的固有问题，解决方法是配置DNS前置调度策略，让DNS请求优先调度到和目标同运营商的DNS服务器。

第二条路径是DNS服务器本身离线。去【系统概况】-【DNS状态】页面看DNS服务器列表里的服务器是否在线，离线的服务器不会参与调度。DNS服务器被判离线的常见原因有两个：服务器本身不可达，或者监视域名有问题。AD通过定期请求监视域名来判断DNS服务器的可用性，监视域名解析失败会让服务器被误判离线。把监视域名换成常见且稳定的域名，能减少这类误判。

如果没有启用DNS代理，DNS请求会走智能路由。此时检查ISP地址段里是否包含内网用户填写的DNS服务器地址——如果用户填的是公网DNS，而ISP地址段里没有这个DNS服务器的IP，DNS请求就会落到default策略，解析路径不再受控。

4. DNS代理不生效与深信服AD的DNS服务配置核查

DNS代理不生效的问题，报障现象一般是两种：内网用户配置了AD接口地址作为DNS，但解析请求没有走代理；或者解析持续失败。这块的故障绝大多数是配置不当造成的，设备本身出问题的概率很低。核查点集中在五个位置：DNS监听地址、DNS服务器列表、客户端DNS指向、DNS服务器在线状态、调度策略。按这个顺序走一遍，基本能覆盖所有常见场景，这也是深信服AD配置DNS服务时最容易踩坑的五个位置。

4.1 DNS代理与智能路由的优先级关系

排错之前先明确DNS代理在整个链路中的位置。AD启用DNS代理后，内网PC把DNS指向AD接口地址，AD收到UDP 53请求后根据调度策略选一台DNS服务器转发请求，拿到应答再返回给PC。DNS代理模块是一个独立的选路单元，它的优先级高于智能路由——也就是说DNS代理启用时，DNS请求完全不经过智能路由选路。这是一个容易被忽略的设计，很多现场在智能路由里反复调规则想解决DNS问题，实际完全没有作用。

同时也意味着，如果DNS代理没有启用，DNS请求才走智能路由，此时DNS解析的选路受智能路由的ISP地址段和default策略控制。排错的第一步永远是确认DNS代理的启用状态，再决定检查方向。

4.2 DNS监听地址：PC指向AD接口，但代理没有监听

DNS代理不生效的第一大原因是监听地址配置缺失。AD只处理发往监听地址的DNS请求，配置了DNS代理但监听地址列表为空时，AD收到DNS报文会直接丢弃或按路由表转发，代理完全不生效。PC的DNS写的是AD的LAN口地址，但这个地址没有出现在监听列表里，请求进不来。

检查时打开DNS监听地址配置页，把AD设备上所有需要接收DNS请求的接口地址都加进去。这里容易漏的是HA地址和子接口地址——高可用环境下PC可能把DNS填成浮动地址，VLAN环境下不同网段的PC会指向不同子接口。每一个充当客户端DNS入口的地址都要在监听列表里有对应条目。

4.3 DNS服务器列表与客户端DNS指向

第二个核查点是DNS服务器列表。DNS代理需要把请求转发给上游DNS服务器，列表为空则代理没有转发目标。列表中建议配置不同运营商的DNS服务器地址各一个，配合调度策略做运营商匹配。同时要检查这些服务器的在线状态，查看【系统概况】-【DNS状态】，离线的DNS服务器不会参与调度，列表里服务器全部离线时代理同样失效。

客户端侧也要核查。PC的DNS设置必须填写AD的DNS服务器列表地址，或者AD的LAN口地址。现场常见的问题是PC的DNS写成了公网DNS地址，比如223.5.5.5，解析请求直接绕过AD出公网，DNS代理被完全避开。这种情况从AD上看不到任何DNS代理日志，因为请求根本没到AD，排查时容易被误导到设备故障方向上。

4.3.1 双地址填写时的优先级

有些现场同时给PC配置了主备DNS地址，主地址写AD接口，备地址写公网DNS。操作系统会在主DNS超时后自动切换到备用DNS，如果主DNS的响应不稳定，大量请求会走备用DNS，表现为DNS代理有时生效有时不生效。建议主备都填AD的地址（不同接口IP），或者在AD侧把响应时间调优，避免客户端触发切换。

4.4 用dig验证DNS代理的实际生效路径

配置核查完成后，用dig命令验证DNS代理是否真正生效。在AD内网侧的客户端上执行指定DNS服务器的解析请求：

# 指定AD接口地址作为DNS服务器，观察响应来源（示例地址按实际环境替换） dig @192.168.1.1 www.example.com +time=2 +tries=1 # 对比：直连公网DNS的结果 dig @223.5.5.5 www.example.com +time=2 +tries=1

命令说明：dig @192.168.1.1把解析请求发到AD接口，+time=2限制等待超时2秒，+tries=1禁止自动重试，避免超时后无限等待。如果第一条命令返回应答且响应中的SERVER一栏显示192.168.1.1，说明DNS代理路径是通的。对比第二条直连公网DNS的结果，如果直连正常但走AD失败，问题就锁定在AD的DNS代理配置上，接下来回到监听地址和服务器列表核查。

4.5 DNS调度策略：轮询之外的选择

DNS服务器的调度策略直接影响解析质量和稳定性。默认的轮询或加权轮询策略在单运营商场景下没有太大问题，但在电信和联通双运营商DNS的场景下，轮询可能把电信用户的请求调度到联通DNS，导致解析结果不理想甚至解析失败。前面3.5节提到的DNS前置调度策略就是针对这个问题的方案，它根据请求来源和目标选择对应运营商的DNS服务器，把解析请求固定到同运营商的服务器上。

5. 把排错固化成验证基线：路由测试、监视器调优与配置模板

5.1 新设备配置起步基线

经过前面几条线的排查，可以把经验沉淀成一套新设备配置基线。繁忙保护比例直接设99%，两条线路一电信一联通时禁用繁忙保护；会话保持掩码从255.255.255.255起步，内网按VLAN划分后再按网段放宽；链路监视器选两个不同运营商的稳定公共地址，避免单一地址抖动导致误判；DNS监听地址在建接口时就同步维护，不等用户报障再补。这些参数在开局阶段设好，能省掉后续大量排障时间。

5.2 三页面快速定位组合

链路状态、路由测试、DNS状态三个页面组合使用，可以在几分钟内完成一轮有效排错。链路状态看线路是否在线和繁忙，路由测试看配置层面的选路意愿，DNS状态看DNS服务器的可用性。三个页面的信息互相印证：路由测试显示应走WAN1但流量实际走WAN2，查看会话保持和链路状态；DNS服务器频繁离线，查看监视域名和服务器可达性。遇到报障时先在这三个页面各截一张图，留存现场证据，再动手改配置。

5.3 验证脚本模板

# 出站选路基础验证：DNS代理连通性 + HTTP出站响应 AD_DNS="192.168.1.1" TARGET="http://www.example.com/" echo "== DNS proxy check ==" dig @$AD_DNS www.example.com +time=2 +tries=1 | grep -E "SERVER|ANSWER" echo "== HTTP egress check ==" for i in $(seq 1 10); do curl -s -o /dev/null -w "round $i: %{http_code} %{time_total}s\n" $TARGET sleep 2 done

脚本把DNS代理连通性和HTTP出站响应放到一轮验证里，先确认DNS解析路径，再确认HTTP数据出站。grep -E "SERVER|ANSWER"提取应答服务器和答案记录数；curl循环输出每次请求的状态码和耗时。拔线测试时保持脚本运行，可以同时验证DNS代理的切换和智能路由的重新选路，比单纯ping要准确得多。运行前把AD_DNS和TARGET替换成实际环境的值，如果AD启用了DNS代理但PC用的是其他DNS入口，要把目标地址改成实际生效的接口IP。

本文还有配套的精品资源，点击获取