简介：一份面向网络运维工程师的深信服AD智能路由排错指导PPT，以故障现象为线索，覆盖智能路由不生效、出站链路负载不均、DNS解析异常及DNS代理失效等场景，系统梳理从配置检查、链路状态确认到路由测试的完整排查路径。资源包共1个pptx文件，大小608KB，内容结构清晰，适合负责深信服AD设备日常运维与故障定位的IT人员参考学习，也适合网络技术学习者熟悉设备选路与代理排错逻辑。目前已吸引135人浏览学习。PPT重点覆盖三类高频问题：智能路由不生效时如何逐步校验规则匹配与出站会话保持；上网时快时慢、DNS解析异常时如何区分DNS代理与智能路由的选路逻辑；DNS代理不生效时如何检查监听地址、DNS服务器列表及客户端配置。每个场景均配有现象分析、可能原因和具体操作建议，例如调整繁忙保护比例、使用DNS前置调度策略、验证DNS服务器在线状态等，可帮助读者快速搭建排错思路，减少现场排查时间。
1. 智能路由不切换：问题往往不在“路由”
生产环境的 AD 上配了两条运营商出口，专线带宽告警时想切一部分流量到备份链路，策略改完保存，等了十分钟，流量纹丝不动。再一看设备状态，健康检查显示备份链路早就 UP 了——配置没写错，链路也没问题，可流量就是不往新策略上走。这类“智能路由不听话”的问题，一线排错时最常见，而且九成都不在路由本身，而是卡在策略命中、健康检查判定、会话保持这三层联动上。
深信服的 AD（应用交付）设备里的“智能路由”，和路由器上的策略路由完全是两回事。它不光看目的地址，还要结合应用类型、源地址、链路实时健康状态一起决定出口。排错的难点也在这：现象一样，根因可以完全不同——可能是健康检查把业务探活误判成链路宕机，可能是策略优先级撞了，更可能是会话保持把老连接钉在旧链路上。下面按判定链路的顺序把原理、诊断命令和参数调整一次讲透。
2. 智能路由的判定链路：健康检查、策略优先级与会话保持
2.1 从链路池到选路：一次转发背后的三次判定
智能路由在 AD 上的执行路径，可以拆成三次独立判定。第一次是策略匹配：报文进入设备后，先匹配虚拟服务或应用识别结果，再按智能路由策略列表从上到下比较源地址、目的地址、应用、时间等条件，命中的那条策略决定流量交给哪个链路池。第二次是成员选择：链路池里有多条链路（多运营商出口、专线、MPLS 接入等），设备根据成员的健康状态、权重、当前连接数选一条实际出口。第三次是会话维持：连接建立后，后续报文不再重新选路，而是直接跟随会话表里记录的出口链路，直到会话老化或被强制清理。
这三次判定看起来独立，实际排错时互相牵连。最典型的一个盲区是：策略命中了，链路池里也有 UP 的成员，但流量还是从旧出口走，原因就在第三次判定——会话还没老化。另一个盲区是健康检查和业务探活混为一谈：健康检查探的是一个“链路可达性”，而不是“业务成功率”，两个概念错位时，链路明明通着却被标记 DOWN，策略只能退到备份链路。
2.2 健康检查的判定参数：改错一个字段就会误判
健康检查是智能路由的“眼睛”。AD 上常见做法是给链路池的每个成员配置独立的探测规则，常见类型有 TCP、HTTP、ICMP、DNS 四种，参数差异直接影响判定结果。
| 参数 | 常见取值 | 作用 |
|---|---|---|
| 探测类型 | TCP / HTTP / ICMP / DNS | 决定探测到哪一层，TCP 只看端口通不通，HTTP 会检查返回状态码 |
| 探测目标 | IP 或域名 | 建议写内网或运营商提供的探测地址，不要写业务公网域名 |
| 间隔 | 3～10 秒 | 太短容易抖动误判，太长会导致故障发现慢 |
| 超时 | 2～5 秒 | 超过即认为单次探测失败 |
| 失败次数 | 2～5 次 | 连续失败达到阈值才标记 DOWN，避免瞬时抖动触发切换 |
| 成功次数 | 1～3 次 | 达到该次数才标记 UP，避免恢复判定过早 |
最隐蔽的坑在探测目标上。曾经遇到一个案例，健康检查把探测目标写成了业务域名 ad.example.com，结果内网 DNS 解析偶发超时，健康检查就判定链路 DOWN，流量全部切到备用线路上，备用带宽被打满后业务整体变慢。后来把探测目标改成运营商提供的网关 IP，用 TCP 探测 80 端口，问题立刻消失。记住一条原则：健康检查探的是链路，不是业务。如果一定要探业务，单独建业务健康检查，不要让它参与链路的 UP/DOWN 判定。
2.3 优先级、备份与会话保持：为什么路由“不切”
策略优先级用数字表示，数字小的先匹配，匹配即停。很多排错场景里“改了策略不生效”，其实是新策略的优先级排在旧策略后面，流量根本走不到新策略。查看优先级时不要只看数字大小，还要看条件的严格程度——紧匹配的规则要放在宽匹配前面，否则宽匹配会把流量先“吃掉”。
备份策略的设计也要留意。常见做法是给链路池配“全部成员 DOWN 时启用备份”，但很多运维把这个和“成员权重为 0 时按备份出口”混淆。权重为 0 的成员仍然参与调度，只是不分配新连接；备份出口则是完全不同的策略分支，只在主链路池不可用时才接管。
会话保持是“不切换”的另一大原因。AD 上默认对 HTTP 会话按源 IP 做保持，老化时间从几分钟到几小时不等。链路切换演练时，如果只改了策略而不清理会话表，在线用户的新连接会继续走上一条链路——因为会话表里已经记录了出口。后面 4.1 节会给出清理命令和判断方法。
3. 用AD控制台与CLI快速定位：关键状态、会话与日志
3.1 Web控制台里先看这三张页面
登录 AD 的 Web 控制台，第一个看“链路池/服务”状态页，里面每个成员的 UP/DOWN、当前连接数、权重一目了然。这里先确认一个事实：你期望走的新链路到底是不是 UP。如果这里显示 DOWN，后面的策略调整全部白做。
第二张是智能路由策略列表页。重点看两个字段：策略的命中次数和最后命中时间。把鼠标移到策略行上，展开详情，能看到该策略匹配了多少个包、多少字节。如果命中次数一直是 0，说明流量根本没匹配到新策略，问题在策略条件或优先级。如果命中次数在涨但出口没变，问题大概率在会话保持。
第三张是实时会话页。按源 IP 或目的 IP 过滤，能看到当前连接实际走了哪条出口链路。这张表能直接回答“用户到底从哪个出口出去的”。会话页里通常还会显示会话的老化剩余时间，判断“等一会会不会自己切过去”就靠这个字段。
3.2 CLI诊断：show命令与关键字段
Web 控制台看不了太细的数据时，上 CLI 更快。不同版本的 AD 命令风格有差异，下面以通用的 show 风格为例，重点是思路：
# 查看链路池成员的健康状态、权重、当前连接数 show link-group status # 查看健康检查最近一次的结果和失败原因 show health-check result # 查看智能路由策略的命中统计 show policy-route hit # 按源地址查会话表，确认实际出口 show session table match source-ip 10.10.1.88 # 查会话老化时间配置 show session aging time逐条看输出里的关键字段。link-group status里的状态列，UP表示健康检查通过，DOWN表示失败，还会带一个最近失败原因，比如timeout或http-status-error。health-check result里能看到探测目标的响应时间，如果响应时间一直在超时边缘徘徊，大概率是探测目标选得不合适。policy-route hit里的命中数是排错的“破案关键”，先看它，再决定往哪个方向查。
3.3 从日志找切换失败的真正原因
控制台和 CLI 解决“当前是什么状态”，日志解决“什么时候开始不对”。AD 的系统日志里会记录健康检查状态翻转事件，比如link-group member 192.0.2.1 status changed from UP to DOWN。搜这个关键字，能看到所有链路的健康状态变更时间线。
操作日志同样重要，记录的是谁在什么时间改了哪条策略。有一种情况经常让人困惑：排错排了半天，最后发现方法是同事在几分钟前把策略改回去了。先看操作日志，能省掉一大半无用功。
需要注意的是，日志里完全没有健康检查翻转记录，但用户反馈“不切换”时，说明健康检查判定链路一直是正常的，问题出在策略匹配或会话保持，别再往健康检查上死磕。反过来，日志里全是 DOWN/UP 频繁交替，就是健康检查参数过于敏感，先调参再谈策略。
4. 四个高频故障的排错步骤与参数调整
4.1 链路切换不生效：先分清是策略没命中还是会话被钉住
切换不生效是最常见的工单。接到这类问题，按三步走。
第一步，看链路池成员状态。两条链路都是 UP 的情况下，问题才可能在策略或会话层。如果期望切换的那条链路本身是 DOWN，先去查健康检查，别动策略。
第二步，看策略命中统计。在控制台上找到目标策略，观察命中次数有没有增长。结合业务访问量判断：如果业务有人在用，命中数却是 0，是策略条件不匹配——检查源地址段、应用类型、目的端口写得对不对。如果命中数在涨，出口链路没变，进入第三步。
第三步，清会话。确认策略没问题的前提下，把相关源地址的会话强制老化：
clear session table match source-ip 10.10.1.0/24这个命令会立刻清掉该网段所有既有会话，后续新请求会重新走策略判定。执行前要确认命令作用范围，生产环境建议按源 IP 粒度清，不要一把梭把全设备会话清空，否则在线 TCP 连接全部中断，影响面不可控。清完会话再看实时会话表，确认新连接从预期出口走。
提示：割接窗口做完策略变更，习惯性清一次相关会话。智能路由的切换只对新连接生效，老连接要等会话老化，不是设备不执行策略，是会话表在“维持旧状态”。
4.2 健康检查误判：TCP探测的局限与HTTP探测的写法
健康检查误判有两种相反的表现：链路通着却标记 DOWN，或者链路已经断了还显示 UP。前者导致流量白白切走，后者导致流量全打到一条坏链路上。
TCP 探测只验证“端口能连上”，三层通、端口开着就算 UP。对于只承载 TCP 业务的链路，这通常够用。但很多链路上跑的是 HTTP 业务，TCP 能连不代表业务正常——后端服务返回 500，TCP 握手照样成功。这时用 HTTP 探测更有意义。
一个可参考的 HTTP 健康检查配置，写成习惯性的配置块：
探测类型: HTTP 探测目标: http://192.0.2.10/healthz 请求方式: GET 期望状态码: 200 间隔: 5秒 超时: 3秒 失败次数: 3 成功次数: 2注意探测路径要选一个响应快、不依赖数据库和缓存的静态接口。曾经有人把探测路径写到登录接口，登录接口在高并发时会限流，返回 503，健康检查就跟着误判。另一个要点是：不要探测公网域名，原因见 2.2 节。如果一定要探测域名，先在 AD 上配好 DNS 服务器地址，并确认解析稳定。
调整参数时，不要只调失败次数。把失败次数从 3 调到 10 能减少误判，但故障发现时间会从 15 秒变成 50 秒，业务影响更大。更稳妥的做法是适当加大间隔和超时，保持失败次数在 2～4 之间，既抗抖动，又不会让故障发现太慢。
4.3 DNS解析走了错误出口：AD配置DNS服务时的联动问题
AD 上如果开启了 DNS 服务功能，内网终端的 DNS 请求也会进入智能路由的调度范围。常见故障是：内网用户解析一个公网域名，结果 DNS 请求从备份链路出去了，解析结果比走主链路慢，或者解析出来的地址不对。
原因是 DNS 请求匹配到了普通的智能路由策略，被当成普通流量负载均衡到多条链路。DNS 请求需要的是“稳定出口”，而不是负载均衡。解决办法是给 DNS 流量单独建一条高优先级策略。
策略优先级: 10 源地址: 内网网段 10.10.0.0/16 目的端口: UDP 53 / TCP 53 应用: DNS 动作: 指定出口 -> 主链路池策略优先级 10 放在最前面，DNS 请求先匹配这条，直接走主链路池。其他流量继续按原有策略走负载均衡。这样避免了 DNS 请求在不同链路间漂移，解析延时和结果一致性都更可控。注意源地址要写内网网段，如果漏了，外网来的 DNS 请求也会被这条规则接管，行为未定义。
配置完测试方法：在终端执行nslookup example.com，然后在 AD 的实时会话页里按源 IP 过滤，确认 DNS 请求的出口链路是主链路。连续解析多次，出口不应变化。
4.4 负载严重不均：会话保持把流量钉死了一条链路
两条链路带宽一大一小，想按 7:3 分流，配好了权重，结果主链路跑满了，备份链路还是空的。这种情况十有八九是会话保持的老化时间过长，把大量连接“粘”在了第一条链路上。
会话保持的判定逻辑是：同一个源 IP 的第一个连接选好链路，后续连接在老化时间内都走同一条。老化时间设为 1 小时的话，一个办公网出口 IP 下的所有用户会被绑定到同一链路长达 1 小时，权重分配只能在“新 IP 第一次建立会话”时生效。
排错时在会话页按源 IP 排序，能看到大量会话集中在少数几个 IP 上。调整方向有两个。一是把会话保持老化时间从 3600 秒降到 300 秒，让老连接更快释放，新连接才有机会重新分配。二是对非关键业务关闭会话保持，或者改成“仅首包绑定”模式——只在第一个包时选路，后续包按目的地址哈希重新分布，适合下载类、视频类等无状态业务。
| 业务类型 | 会话保持策略 | 老化时间建议 |
|---|---|---|
| 网页门户 | 按源 IP 保持 | 300～600 秒 |
| 企业 OA、ERP | 按 Cookie 保持 | 与登录态有效期一致 |
| 文件下载、视频点播 | 不保持或首包绑定 | 不设老化 |
调整后的验证方法：观察两条链路的实时连接数曲线，权重 7:3 的链路池，连接数比例应该接近 7:3，带宽占用比例也同步接近。如果连接数均匀了但带宽还是不均，说明单条大连接（比如视频流）占的带宽远超普通小连接，这时要在应用层做限速，而不是改智能路由参数。
5. 链路切换演练与抓包验证：把排错做成例行操作
5.1 定时记录健康检查状态，反向定位“几时开始不切”
很多时候接到报障，故障已经持续了一段时间，日志里虽然有健康检查翻转记录，但要人肉翻到具体时间点很费劲。常见做法是提前做一个定时采集脚本，把健康状态变化持续记录下来。
while true; do echo "$(date '+%F %T') $(show health-check result | grep -E 'link-group|status')" >> /var/log/ad_link_health.log sleep 60 done这个脚本每 60 秒把健康检查结果和当前时间追加到日志文件。设备如果有外部日志服务器，也可以直接把日志转发到服务器上再切割归档。后面排错时直接按时间搜这个文件，能精确看到某条链路在哪一分钟变成 DOWN、在哪一分钟恢复。没有历史状态文件，就只能凭印象猜，效率低很多。
配合日志服务器的话，再加一个简单的 diff 判断，状态变化时自动打一条标记：
tail -n 1 /var/log/ad_link_health.log | md5sum > /tmp/last_state while true; do current=$(tail -n 1 /var/log/ad_link_health.log | md5sum) if [ "$current" != "$(cat /tmp/last_state)" ]; then echo "$(date '+%F %T') STATE CHANGED: $(tail -n 1 /var/log/ad_link_health.log)" >> /var/log/ad_link_change.log echo "$current" > /tmp/last_state fi sleep 60 done这样长期运行后，ad_link_change.log里就是一份干净的状态变更时间线，哪条链路什么时候抖动的，一清二楚。
5.2 用抓包确认切换前后流量走了哪条链路
配置层面的验证做完，最后一步是抓包确认数据面真的按预期走了。在 AD 的物理接口上抓包，分别对应主链路的出接口和备份链路的出接口。
tcpdump -i eth1 host 10.10.1.88 and tcp port 443 -nn tcpdump -i eth2 host 10.10.1.88 and tcp port 443 -nneth1 对应主链路接口，eth2 对应备份链路接口。挑一个测试源 IP，清掉会话后发起访问，观察两个接口的抓包窗口：切换前在 eth1 能看到流量，切换后流量应出现在 eth2 上。如果两侧接口都在抓包，但流量从哪个接口都不出去，说明报文可能走了设备内部的快速转发路径，没经过这两个物理接口的抓包点，需要换抓包点位。
双机部署的场景还要多确认一步：流量是经过了主设备还是备设备。设备切换和链路切换是两个独立事件，单看链路抓不到包时，检查双机状态和接口联动配置，避免把设备主备切换误判成智能路由故障。演练完成后，把脚本记录的日志、抓包文件、策略变更内容和操作时间记到一处，下次再出同类问题，回翻记录能省一半排查时间。
本文还有配套的精品资源，点击获取
