简介：面向企业网络运维与 IT 管理人员的解决方案类 PDF 文档，围绕深信服 AD 智能 DNS 与虚拟服务常见故障，提供从现象定位到配置修复的完整排查思路。文档以智能 DNS 数据流为主线，逐步讲解 NS 记录核对、AD 设备参数校验、Wireshark 抓包确认解析路径，并针对虚拟服务访问不到的问题，依次检查服务器服务、链路状态、前置策略、节点状态、SNAT 路由及会话保持方式，形成可落地的排错清单。内容还包含 nslookup 验证 NS 记录、区分四层/七层负载、端口映射与虚拟服务优先级等实用细节，适合正在部署或维护深信服 AD 设备的网络工程师对照使用。资源为单份 PDF，大小 569KB，已有 208 人学习/下载，可按章节快速定位故障原因并制定处理方案。此外，针对旁路模式部署下的 SNAT 和路由配置也有专门提示，可避免因网络路径错误导致服务不可达。

1. 这份“最佳实践”PDF，其实在讲两件事：DNS 要怎么调度，流量要怎么发布

做运维或网络的人拿到“深信服 AD智能DNS及虚拟服务最佳实践.pdf”这个标题，第一反应应该是：这是一份讲深信服应用交付（AD）设备怎么把“域名解析”和“流量转发”两件事做扎实的配置文档合集。它不是让你理解 DNS 协议本身，而是告诉你生产环境里智能DNS 策略、虚拟服务（vServer）参数、健康检查阈值这些旋钮到底该怎么拧。想解决的问题也很直白：多链路时用户访问不绕路、后端服务器挂了流量不丢、弹性伸缩时连接不中断。适合谁？正在用深信服 AD 替代 F5、或者刚接手一套 AD 设备但只敢动动 Web 界面的运维工程师。读完你至少能把“解析调度”和“流量发布”这两条线的配置逻辑理顺，并知道哪些参数改错了会引发现网事故。

2. 智能DNS 的落地：链路负载与地域调度的配置思路

很多人在智能DNS 上翻的第一个跟头，是把它当成“高级版 DNS 解析记录”来配。结果解析策略配了一堆，链路切换却迟迟不生效。问题出在哪？出在没理解智能DNS 的根本任务不是“解析”，而是“调度”——它要根据来访者的地域、运营商、链路健康状态，决定把域名解析到哪一条出口链路上。

2.1 先搞清智能DNS 解决的是哪一类问题：一个域名背后的三张网

典型的场景是：公司有电信、联通、移动三条出口链路，后端业务同时服务三个运营商的用户。如果 DNS 只配一条 A 记录，电信用户访问时可能被解析到移动链路上，跨网绕行带来的延迟和丢包立刻就让业务“感觉变慢”。智能DNS 要解决的，就是在解析阶段就把用户导向最优链路。

所以配置之前，第一步是盘点你的链路资产。常见做法是给每条链路建一个“视图”或“地址池”，视图里写清楚这个池对应哪个运营商、哪条出口、优先级是多少。深信服 AD 的控制台里，这个逻辑通常落在 DNS 服务下的“智能解析策略”模块，一条策略由三部分组成：匹配条件（来源 IP 或地域）、可用的解析结果（通常是虚拟服务地址或链路出口 IP）、以及 failover 顺序。

2.2 最小配置：把一条 A 记录变成按链路调度的解析策略

先看一个最小可行的配置流程，假设你有两条链路，电信和联通，各有一个公网 IP：

这套配置的意义在于：大部分 DNS 请求来自电信用户，它们命中电信视图，直接解析到电信 IP；联通用户命中联通视图；识别不了的来源（比如海外）落到默认记录，保证解析不空。注意这里有一个关键点：视图的匹配是基于“来源 IP 归属”，不是基于用户自己声明的运营商，所以设备内置或自建的 IP 地址库质量会直接影响调度准确性。

2.3 地域解析与运营商线路识别：参数怎么设才算“智能”

“智能”两个字最容易让新手误解。以为智能就是设备自己学习、自己决定。实际上智能DNS的所有调度行为都来自策略组，你给什么规则，它就执行什么调度。所谓的智能，主要体现在两个方面：一是来源识别做得细，能区分到一个 IP 段甚至一个地区；二是链路健康探测和自动切换做得快，链路故障能在几秒内把解析结果切到存活链路上。

实际操作时，我一般会把地域策略拆成两层。第一层按运营商划分，把国内三大运营商放到优先级最高的视图；第二层再按省份细分，比如广东电信、北京联通单独建视图。这样做的原因是，某些省份的跨网质量差异极大，按大区粒度调度根本不够。参数上，来源匹配的“优先级”要高于“默认记录”，但两条视图之间要注意重合的 IP 段——如果电信 IP 库里混入了少量联通 IP，这部分用户的解析结果就会飘。所以配置完成后，建议抽样几个知名 IP（比如 DNS 服务器 IP、网站首页的客户端出口 IP）做解析验证。

2.4 解析结果被缓存了怎么办：TTL 与解析优先级

智能DNS最容易引发的投诉是：我已经切了链路，用户那边迟迟不生效。原因几乎都在 TTL。传统 DNS 记录把 TTL 设成 3600 甚至更长，是为了减少查询压力。但在智能DNS 场景下，TTL 过长会让链路切换后的收敛时间变得不可接受。

建议把智能DNS 的 TTL 设置在 60～300 秒之间。追求快速切换的链路，TTL 压到 60 秒；对切换容忍度高的域名可以放宽到 300 秒。另外要注意：TTL 是下发到递归服务器和终端的，你的 AD 设备只是“发布方”，不能强制让别人的递归缓存提前过期。所以重要割接前，提前 30 分钟把 TTL 调低，让全网缓存先散掉，这是运维老手的常规操作。另一个容易被忽略的点是：来源 IP 库导入后要定期更新，运营商 IP 段是变动的，地址库过期会让调度结果逐渐失真。

3. 虚拟服务核心配置：四层与七层发布的参数取舍

智能DNS 把用户流量引到了正确的入口 IP，接下来要处理的是：这些流量进来之后，AD 设备怎么把它分发给后端的服务器。这就是虚拟服务的职责。虚拟服务的配置决定了流量的转发模式、负载算法、会话保持和健康检查策略，它才是业务稳定性的真正底仓。

3.1 四层虚拟服务：IP+端口转发的最小配置

四层虚拟服务适合数据库、OA 系统、以及不做复杂 HTTP 决策的 TCP 业务。它的核心配置项是：虚拟 IP（VIP）、虚拟端口、后端真实服务器（RS）列表、负载算法、健康检查方式。

四层转发模式下，AD 默认做 SNAT 改造或者三角传输，这取决于设备的部署模式。我一般建议用网关模式（AD 作为业务入口网关），客户端到虚拟 IP，AD 再与后端建立新连接。这样做的代价是连接数会翻倍，但好处是后端服务器不需要额外配置指向 AD 的回程路由，排障链路更简单。

3.2 七层虚拟服务：域名、URL 与 TLS 终结的逻辑

七层虚拟服务解决的是“按内容转发”的问题。同一个 VIP 上挂了多个域名，或者同一个域名下需要按 URL 路径分发到不同后端集群，这时候必须用七层。典型配置是按域名分流：www.example.com走集群 A，api.example.com走集群 B，两条后端路径分别做负载。

配置七层虚拟服务的核心是“内容规则”的定义。在深信服 AD 的控制台上，一般是在虚拟服务里添加“内容策略”，策略由“匹配条件 + 动作”组成：

这里有一个设计取舍：如果后端已经有 HTTPS 证书，你仍然建议让 AD 做 TLS 终结。原因是七层策略必须读到 HTTP 头，而 TLS 是加密的，AD 不解密就看不到 Host 字段。要么 AD 终结 TLS 然后再向后端发起新 TLS 连接（三段握手，性能损耗最大），要么 AD 终结 TLS 后与后端走 HTTP（内网可以接受，配置最省）。

3.3 负载算法怎么选：轮询、最小连接还是源地址 hash

负载算法的选择经常被当成小事，它恰恰是翻车高发区。轮询（round robin）适合请求处理时间接近的场景；最小连接（least connection）适合长连接、请求耗时差异大的场景；源地址 hash 适合需要按用户 IP 固定后端的场景。很多默认配置都是轮询，但真实业务里，处理一个请求耗时从 50ms 到 5s 不等，轮询会把慢请求堆积在某台机器上。

我一般这么选：普通 Web 服务用 least connection；数据库中间层用 least connection + 连接复用；带本地缓存、希望同一用户始终命中同一台后端的使用源地址 hash，但要提前评估服务器数量变化带来的 hash 重分布影响。另外要关注虚拟服务是否开启了“连接复用”（七层 HTTP keepalive 复用），开启后同一后端连接会被多个客户端请求使用，此时最小连接的统计口径要从“新建连接数”变成“活跃连接数”，否则算法会失真。

3.4 虚拟服务与智能DNS 的配合关系

这一节容易被忽略，但它是整份配置的骨架逻辑。智能DNS 负责把“外部用户”解析到“正确的入口”，虚拟服务负责把“入口流量”分发到“正确的后端”。两者配合时，有一个硬原则：虚拟服务的 VIP 必须是智能DNS 解析结果里的那个 IP，不能让用户解析到链路出口 IP，然后链路出口 IP 上没有任何虚拟服务在监听。

实践中见过一个案例：智能DNS 解析结果是 A 链路 IP，但虚拟服务 VIP 配的是 B 链路 IP，结果用户从 A 链路进来，发现目标地址没有服务监听，连接被拒绝。排错时从解析查起，一层层往下找，最后才发现是 IP 没对上。所以配置清单里应该加一条校验项：每个智能DNS 解析结果 IP，都必须在虚拟服务列表里有对应的监听。

4. 健康检查与会话保持：让虚拟服务稳定的两个关键旋钮

虚拟服务的配置框架搭好之后，真正决定业务连续性的往往不是转发逻辑，而是两个容易被当成“辅助功能”的模块：健康检查和会话保持。它们在故障场景下才是主角。

4.1 健康检查：从“ping 通”到“业务通”的距离

不少团队的健康检查停留在“ping 后端 IP”的层面，这在后端宕机时能发现问题，但应用卡死、端口假活、数据库连接池耗尽这类故障，ping 是探不出来的。健康检查的深度必须从“网络通”推进到“业务通”。

对于 HTTP 服务，建议使用 HTTP 健康检查，探测一个轻量级 URL（比如/healthz），要求响应码为 200 才算健康。对于 TCP 服务，至少要端口探测；对于数据库、Redis 这类带协议的服务，最好用协议探测。参数上，健康检查的间隔、超时、失败阈值需要和虚拟服务的切换速度联动：

常见的错误是把失败次数设成 1 次，结果后端一次 GC 停顿或者网络抖动，整台机器被摘除，流量全部压到另一台。反之失败次数设成 5 次，故障切换时间会被拉长到十几秒，用户侧已经能感知到连接失败。建议的折中是 3 次失败摘除，配合 3 秒间隔，大约 10 秒完成切换，这个时间对大多数业务是可接受的。

4.2 会话保持：Cookie、源 IP 与一致性 hash 的取舍

会话保持的作用是让同一用户的多个请求落到同一台后端，避免因为请求被分散到不同节点而丢掉 Session。最常见的需求是：用户登录后，后续请求必须命中登录时的那台服务器。

实现方式有三种：Cookie 插入、源 IP hash、HTTP 头 hash。Cookie 插入是最推荐的方式：AD 在响应里插入一个会话 Cookie，后续请求携带该 Cookie，AD 据此固定到同一后端。它的优点是精确到会话级别，不依赖用户 IP（解决同一个 NAT 出口下多个用户被误判为同一来源的问题）。源 IP hash 的优点是配置简单，但缺陷也明显：一个办公室几十号人从同一个公网 IP 出去，hash 会把所有人都分到同一台后端，负载完全失衡。HTTP 头 hash（比如根据X-User-ID头）适合有明确用户标识的业务，效果最好，但要求业务方配合改造。

4.3 慢启动与连接耗尽：两个常被忽略的保护参数

后端服务器在两种情况下需要“保护”：刚上线时和连接池耗尽时。刚上线的服务器如果立刻被灌入全量流量，应用进程可能因为缓存未预热而响应缓慢，甚至被压垮。所以主流负载设备都有“慢启动”功能：新加入的后端在 30～60 秒内逐步提高接收流量的比例。深信服 AD 里一般叫“梯度上线”或“Slow Start”，建议启用，初始权重设为正常值的 20%～30%。

连接耗尽则是另一个坑：后端的最大并发连接数有限，如果 AD 持续向后端派发新连接，后端可能因为连接队列溢出而大面积拒绝。此时 AD 要做的是“限流”，即当后端健康检查正常但响应时间持续升高时，暂时降低该后端的权重，而不是继续按原权重派流量。这个参数在部分设备上叫“最大连接数限制”或“过载保护”，建议按后端实际处理能力设置，不要用默认的 0（无限制）。

5. 智能DNS 与虚拟服务的 5 个高频坑：现象、原因、处理

这一章写给已经配完、正在排障的人。以下五个坑是我在现网环境里反复见到的，按“现象 → 原因 → 解决”的方式记录，每条都能直接对照自查。

5.1 智能DNS 解析结果“不对”，但策略配置看起来没问题

现象：配置了电信、联通两个视图，但从电信用户侧解析域名，返回的却是联通 IP。原因是：视图匹配有优先级顺序，且默认记录会捕获所有未命中项。你的电信视图可能没包含全部电信 IP 段，部分电信用户被划入了默认记录。

解决：把“默认记录”的链路设为备用链路，并将电信/联通视图的匹配范围落到运营商 IP 库的完整版本上。验证方式：用多个已知归属的 DNS 客户端 IP 发起解析查询，逐条核对解析结果与预期是否一致。不要只测一个 IP 就认为策略生效了。

5.2 业务间歇性超时，虚拟服务却在正常转发

现象：用户反馈访问业务时好时坏，AD 上看到虚拟服务的连接数正常，后端健康检查也全绿。原因是：会话保持配置（或一致性 hash）把同一用户的请求固定到某一台后端，而这台后端的应用日志显示存在周期性慢查询或 GC 暂停，但 TCP 端口仍然活着，健康检查探不出问题。

解决：把健康检查从“端口探测”升级为“HTTP 内容探测”，探测一个能反映真实处理能力的 URL，并在后端应用层配合输出调用链日志。同时检查会话保持策略：如果固定后端的算法导致单机流量过热，考虑改用 Cookie 会话保持，让新会话可以自然分散。

5.3 会话保持不生效，用户频繁被要求重新登录

现象：配置了会话保持，但用户每次刷新都要重新登录。原因是：会话保持类型选错了。用源 IP hash 时，如果用户 IP 在链路切换后变了（比如从 4G 切到 WiFi，或者 NAT 出口变化），hash 结果就会变，会话自然丢。另一种可能是七层虚拟服务没有开启 Cookie 插入，仅用了四层会话保持。

解决：业务需要跨 IP 保持会话时，必须改用 Cookie 方式。确认虚拟服务是七层 HTTP 模式，并在会话保持配置中选择 Cookie 插入，同时检查后端应用是否设置了禁止 Cookie 的响应头——有些安全策略会剥离 Set-Cookie，导致 AD 插入的会话 Cookie 被干掉。

5.4 健康检查全绿，但页面返回 502

现象：后端服务器的进程正常、端口正常、健康检查全绿，但从 AD 访问业务时返回 502。原因是：健康检查探测的是后端某个端口，但实际转发时访问的是另一个端口或另一个 Host。比如健康检查探测 80 端口，虚拟服务却把流量转发到 8080 端口，而 8080 端口的应用依赖某个外部服务（如 Redis），Redis 挂了，8080 端口虽然在听但无法正常响应。

解决：让健康检查的探测目标与虚拟服务的转发目标完全一致，包括端口、Host 头和 URL 路径。建议为每个后端专门配一个健康检查用的 URL，该 URL 不依赖外部服务，仅反映本进程的存活和处理能力。502 排障时，先用 curl 从 AD 手动请求后端的实际地址，看返回什么错误码，再决定是改健康检查还是查后端依赖。

5.5 变更后流量没有切到新节点，用户还在访问旧服务器

现象：后端新加了一台服务器（或下线了一台），但 AD 的流量分发没有按预期变化，新机器迟迟没有流量。原因是：负载算法是源地址 hash，且虚拟服务开启了连接保持（连接复用），旧的 TCP 连接一直存活，hash 表里的映射不会重新计算。新节点加入后，只有当新的连接建立时才有可能被 hash 到，而长连接把绝大多数请求都“锁”在了旧连接上。

解决：变更后如果希望流量尽快重新分配，可以在低峰期重置虚拟服务的连接，或在控制台上选择“清空连接表”。更稳妥的做法是：源地址 hash 只用在确实需要固定后端的场景，普通 Web 负载优先用 least connection + Cookie 会话保持，这样后端节点上下线对流量分配的影响会平滑很多。

6. 上线后的验证技巧：割接时怎么证明配置是对的

最后一章，分享一个我在每次智能DNS+虚拟服务割接后都会执行的最小验证清单，以及一条保命的变更习惯。验证不能只在控制台里看状态，要到用户视角去测。

习惯上，我给自己定了一条铁律：任何变更（改策略、调权重、加节点）都在凌晨低峰窗口执行，并且变更前导出当前配置，变更后立刻对比差异。这个对比动作救过我很多次——有一次改虚拟服务的负载算法，保存时不小心把后端端口也改了，如果没做配置比对，第二天早上业务必然报障。设备配置有“后悔药”功能就立即用，没有就手动备份，这句成本极低，但收益极高。

以上这些参数和验证动作，基本覆盖了智能DNS 和虚拟服务从配置到排障的完整闭环。技术本身不复杂，复杂的是每个参数的取舍和它们之间的联动。希望这次梳理能帮你把这份“最佳实践”变成你自己环境的操作规程，少走几次弯路。

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