简介面向企业网络运维与 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配置项取值示例说明域名www.example.com需要被智能解析的业务域名默认解析记录101.xxx.xxx.1电信链路 IP兜底记录所有未匹配到的来源都走这里电信视图来源匹配中国电信 IP 库命中后解析到电信链路 IP联通视图来源匹配中国联通 IP 库命中后解析到联通链路 IP链路健康检查ping 电信网关 / ping 联通网关链路挂了自动摘除对应视图这套配置的意义在于大部分 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 设置在 60300 秒之间。追求快速切换的链路TTL 压到 60 秒对切换容忍度高的域名可以放宽到 300 秒。另外要注意TTL 是下发到递归服务器和终端的你的 AD 设备只是“发布方”不能强制让别人的递归缓存提前过期。所以重要割接前提前 30 分钟把 TTL 调低让全网缓存先散掉这是运维老手的常规操作。另一个容易被忽略的点是来源 IP 库导入后要定期更新运营商 IP 段是变动的地址库过期会让调度结果逐渐失真。3. 虚拟服务核心配置四层与七层发布的参数取舍智能DNS 把用户流量引到了正确的入口 IP接下来要处理的是这些流量进来之后AD 设备怎么把它分发给后端的服务器。这就是虚拟服务的职责。虚拟服务的配置决定了流量的转发模式、负载算法、会话保持和健康检查策略它才是业务稳定性的真正底仓。3.1 四层虚拟服务IP端口转发的最小配置四层虚拟服务适合数据库、OA 系统、以及不做复杂 HTTP 决策的 TCP 业务。它的核心配置项是虚拟 IPVIP、虚拟端口、后端真实服务器RS列表、负载算法、健康检查方式。配置项推荐取值说明虚拟 IP与智能DNS 解析到同一地址链路 IP 和 VIP 要保持一致避免多跳虚拟端口与应用实际监听端口一致80/443/3306 等后端服务器内网 IP 端口例如 192.168.10.10:3306负载算法四层优先 leastconn四层无法感知应用层负载最小连接更接近真实负载健康检查TCP 端口探测探测间隔 5s失败 3 次标记 down四层转发模式下AD 默认做 SNAT 改造或者三角传输这取决于设备的部署模式。我一般建议用网关模式AD 作为业务入口网关客户端到虚拟 IPAD 再与后端建立新连接。这样做的代价是连接数会翻倍但好处是后端服务器不需要额外配置指向 AD 的回程路由排障链路更简单。3.2 七层虚拟服务域名、URL 与 TLS 终结的逻辑七层虚拟服务解决的是“按内容转发”的问题。同一个 VIP 上挂了多个域名或者同一个域名下需要按 URL 路径分发到不同后端集群这时候必须用七层。典型配置是按域名分流www.example.com走集群 Aapi.example.com走集群 B两条后端路径分别做负载。配置七层虚拟服务的核心是“内容规则”的定义。在深信服 AD 的控制台上一般是在虚拟服务里添加“内容策略”策略由“匹配条件 动作”组成策略字段配置值说明匹配类型Host 字段按域名匹配匹配值api.example.com精确匹配优于泛匹配动作转发到后端池 api-servers不匹配则落到默认池TLS 终结勾选上传证书证书卸载在 AD后端走 HTTP减轻后端压力这里有一个设计取舍如果后端已经有 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 这类带协议的服务最好用协议探测。参数上健康检查的间隔、超时、失败阈值需要和虚拟服务的切换速度联动参数推荐值作用探测间隔35 秒间隔太短会增加后端压力太长会拖慢故障切换超时时间2 秒超过即算本次探测失败失败次数23 次达到后标记后端“宕机”摘除流量成功次数2 次后端恢复后重新纳入流量池的确认次数常见的错误是把失败次数设成 1 次结果后端一次 GC 停顿或者网络抖动整台机器被摘除流量全部压到另一台。反之失败次数设成 5 次故障切换时间会被拉长到十几秒用户侧已经能感知到连接失败。建议的折中是 3 次失败摘除配合 3 秒间隔大约 10 秒完成切换这个时间对大多数业务是可接受的。4.2 会话保持Cookie、源 IP 与一致性 hash 的取舍会话保持的作用是让同一用户的多个请求落到同一台后端避免因为请求被分散到不同节点而丢掉 Session。最常见的需求是用户登录后后续请求必须命中登录时的那台服务器。实现方式有三种Cookie 插入、源 IP hash、HTTP 头 hash。Cookie 插入是最推荐的方式AD 在响应里插入一个会话 Cookie后续请求携带该 CookieAD 据此固定到同一后端。它的优点是精确到会话级别不依赖用户 IP解决同一个 NAT 出口下多个用户被误判为同一来源的问题。源 IP hash 的优点是配置简单但缺陷也明显一个办公室几十号人从同一个公网 IP 出去hash 会把所有人都分到同一台后端负载完全失衡。HTTP 头 hash比如根据X-User-ID头适合有明确用户标识的业务效果最好但要求业务方配合改造。4.3 慢启动与连接耗尽两个常被忽略的保护参数后端服务器在两种情况下需要“保护”刚上线时和连接池耗尽时。刚上线的服务器如果立刻被灌入全量流量应用进程可能因为缓存未预热而响应缓慢甚至被压垮。所以主流负载设备都有“慢启动”功能新加入的后端在 3060 秒内逐步提高接收流量的比例。深信服 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 端口的应用依赖某个外部服务如 RedisRedis 挂了8080 端口虽然在听但无法正常响应。解决让健康检查的探测目标与虚拟服务的转发目标完全一致包括端口、Host 头和 URL 路径。建议为每个后端专门配一个健康检查用的 URL该 URL 不依赖外部服务仅反映本进程的存活和处理能力。502 排障时先用 curl 从 AD 手动请求后端的实际地址看返回什么错误码再决定是改健康检查还是查后端依赖。5.5 变更后流量没有切到新节点用户还在访问旧服务器现象后端新加了一台服务器或下线了一台但 AD 的流量分发没有按预期变化新机器迟迟没有流量。原因是负载算法是源地址 hash且虚拟服务开启了连接保持连接复用旧的 TCP 连接一直存活hash 表里的映射不会重新计算。新节点加入后只有当新的连接建立时才有可能被 hash 到而长连接把绝大多数请求都“锁”在了旧连接上。解决变更后如果希望流量尽快重新分配可以在低峰期重置虚拟服务的连接或在控制台上选择“清空连接表”。更稳妥的做法是源地址 hash 只用在确实需要固定后端的场景普通 Web 负载优先用 least connection Cookie 会话保持这样后端节点上下线对流量分配的影响会平滑很多。6. 上线后的验证技巧割接时怎么证明配置是对的最后一章分享一个我在每次智能DNS虚拟服务割接后都会执行的最小验证清单以及一条保命的变更习惯。验证不能只在控制台里看状态要到用户视角去测。验证项命令/操作通过标准解析调度dig AD_IP www.example.com short返回的 IP 与预期链路一致链路切换断开主链路再次 dig5 秒内返回备用链路 IP虚拟服务转发curl -I http://VIP/healthz返回 200 且 Server 头符合预期会话保持连续请求 5 次观察 Set-CookieCookie 值一致且固定到同一后端健康检查摘除手动停掉一台后端观察虚拟服务状态30 秒内该后端变为 down请求全部落到存活后端习惯上我给自己定了一条铁律任何变更改策略、调权重、加节点都在凌晨低峰窗口执行并且变更前导出当前配置变更后立刻对比差异。这个对比动作救过我很多次——有一次改虚拟服务的负载算法保存时不小心把后端端口也改了如果没做配置比对第二天早上业务必然报障。设备配置有“后悔药”功能就立即用没有就手动备份这句成本极低但收益极高。以上这些参数和验证动作基本覆盖了智能DNS 和虚拟服务从配置到排障的完整闭环。技术本身不复杂复杂的是每个参数的取舍和它们之间的联动。希望这次梳理能帮你把这份“最佳实践”变成你自己环境的操作规程少走几次弯路。本文还有配套的精品资源点击获取