数据库端口仅允许特定IP后访问变慢，如何按DNS、路由丢包与数据库负载分层排查？

数据库端口仅允许特定 IP 访问后变慢，如何按 DNS、路由丢包与数据库负载分层排查？

调整白名单后，数据库连接仍能建立，但应用响应变慢；也可能是连接偶发超时，重试后才成功。两种表现的原因可能不同：仅允许特定 IP 访问数据库端口，本身不会必然增加网络延迟；但如果规则没有匹配数据库实际看到的客户端源 IP，连接可能被拒绝或丢弃，应用再经过重试，就会表现为等待时间变长。DNS 解析、访问路径、服务器负载和应用连接池也都可能产生相似症状。

排查时先固定客户端、数据库地址和端口，确定耗时发生在 DNS 解析、TCP 建连、数据库查询还是应用处理；再依次检查本地网络与源 IP、DNS、路由和丢包、访问控制与服务器状态，最后分析数据库负载和应用等待。每一步都记录时间和结果，避免仅凭“白名单改完后变慢”就认定是白名单或网络的问题。

先确认影响范围和耗时发生在哪一段

排查前记录故障时间、客户端主机、客户端当前出口源 IP、数据库主机名、端口、使用的数据库及应用，以及变慢时的具体表现。若近期修改过访问规则，还应记录规则的来源地址、协议、端口、变更时间和匹配顺序。

可以先用下面的现象表缩小范围。表中的判断是排查起点，不是单一现象对应单一根因。

按顺序执行低风险检查

1. 在客户端区分 DNS、TCP 建连和应用耗时

先从实际发生问题的客户端测试数据库主机名和端口。Linux 示例：

date -Is
getent ahosts db.example.com
time nc -vz -w 3 db.example.com 3306

将 db.example.com 和 3306 替换为实际主机名和端口。getent 可查看系统实际使用的解析结果；nc 用于测试 TCP 端口能否建立连接；time 显示命令总耗时。不同版本的 nc 输出格式可能不同，记录连接成功、失败或超时以及重复测试结果即可。

Windows 示例：

Get-Date
Resolve-DnsName db.example.com
Test-NetConnection db.example.com -Port 3306

如果连接测试超时，不能据此直接认定数据库宕机。可能原因包括访问控制未命中、路径丢包、服务没有监听该端口，或服务器暂时无法响应。若 TCP 建连稳定，而应用仍然慢，应分别记录应用获取连接、发送查询、等待数据库返回和处理结果的耗时。应用总响应时间不等于网络延迟。

测试时固定客户端、目标主机名、端口和方法，在故障时与正常时分别采集记录。单次成功不能排除间歇性故障；不同客户端或不同时间得到的结果，也不能直接当成同条件对照。

2. 确认客户端实际出口和白名单匹配对象

“允许某个 IP”是否有效，取决于数据库服务器实际看到的客户端源 IP，而不一定是客户端网卡上的内网地址。如果客户端经过网络出口转换，服务端观察到的地址可能与客户端本机显示的地址不同。客户端存在多个出口时，应用选用的出口和源地址也可能与预期不一致。

Linux 客户端可先查询到数据库 IP 的路由选择：

ip route get 203.0.113.10

将示例地址替换为数据库主机名解析出的实际 IP。重点检查输出中的出口网卡、下一跳和 src 源地址。这个结果反映客户端本机选择的路由和源地址，不一定能证明服务器最终看到的公网源 IP。必要时，应对照受控的服务端连接日志或网络设备记录确认实际来源。

随后核对访问规则是否覆盖了正确来源、数据库端口和协议，规则顺序是否会影响匹配。如果连接在白名单变更后开始超时，且服务端未看到预期来源的请求，应继续检查客户端出口和中间路径，而不是直接扩大允许范围。不要为方便排障将数据库端口开放给所有地址。

3. 检查 DNS 是否正确，以及等待是否发生在解析阶段

应用使用主机名连接数据库时，客户端需要先解析名称。确认解析结果是否指向预期数据库地址，并核对不同客户端是否解析到相同地址。

Linux 可执行：

getent ahosts db.example.com

如果系统已安装 dig，可补充查询：

dig +time=2 +tries=1 db.example.com

Windows 可执行：

Resolve-DnsName db.example.com

如果解析结果为空、错误，或解析阶段明显等待，而使用已确认正确的 IP 测试 TCP 建连正常，问题更可能出在名称解析环节。此时应检查客户端实际使用的 DNS 配置、搜索域和缓存。清理 DNS 缓存不会修复错误记录，还可能使客户端重新获取当前记录；如需清理，应按操作系统规定操作，并先确认不会影响其他业务。

使用 IP 进行对照时，要确认该 IP 与主机名解析结果一致，并且确实是同一个数据库入口。如果数据库地址配置涉及多个解析结果，只测试其中一个地址不能证明所有地址都正常。对于已经建立并持续复用的长连接，DNS 通常不参与每条查询请求；因此，若连接保持不变而查询变慢，应继续排查数据库和应用层。

4. 对照路由和丢包，不以单一探测结果定因

确认目标 IP 后，检查客户端到目标的路由，并在故障和正常时使用相同客户端、目标和测试方式对比。可用的工具取决于操作系统和环境。例如 Linux 上可运行：

ip route get 203.0.113.10
ping -c 20 203.0.113.10
mtr -rwzc 100 203.0.113.10

如果系统没有 mtr，不要为了排查随意在生产客户端安装软件；可使用当前已获准的网络诊断工具，并记录其测试目标和方法。ping、mtr 使用的探测流量可能被网络策略限制，或者被中间设备降低响应优先级。因此，中间节点不回应探测包，不足以证明业务流量在该节点丢失；ICMP 不通但 TCP 连接和业务正常，也不能仅凭 ping 判断数据库路径故障。

更有价值的证据是：同一客户端到同一目标的 TCP 建连是否间歇性超时，异常时段是否伴随连接重试，以及服务端是否观察到对应的请求。若探测结果有变化但 TCP 和业务均正常，应继续观察，不要仅凭单个中间节点的丢包显示就要求修改路由。若 TCP 建连在同一时段反复失败，应结合两端记录继续定位路径、访问控制或服务器响应问题。

测试记录至少应包含时间、客户端、出口源地址、目标 IP、测试方法、样本次数和结果。没有同一时间段、同一目标和相近环境的对照数据，就不能将不同测试结果直接解释为线路质量变化。

5. 在服务端核对连接是否到达、端口是否正常服务

如果有数据库服务器的运维权限，可在问题发生时核对目标端口是否监听，以及客户端请求是否到达。Linux 上可查看监听状态：

ss -lnt

该命令只用于查看监听信息；应在输出中确认数据库实际使用的端口，而不是假设所有数据库都使用同一个端口。

必要时可以短时抓取限定来源和端口的网络元数据。以下命令适用于已安装 tcpdump 的 Linux 系统，需要相应权限：

sudo tcpdump -nn -i any host 198.51.100.25 and port 3306

将示例客户端地址和端口替换为实际值。抓包会记录网络元数据，应遵循内部安全要求，只在必要时间、限定主机和端口执行，排查后及时停止。不要将抓包内容或相关日志公开传播。

判断时可按以下方式继续：

• 服务端看不到客户端请求： 核对客户端出口源 IP、路由和中间访问控制。抓包未观察到请求不能单独定位具体是哪一段丢弃。
• 服务端收到请求，但没有正常响应： 检查本机防火墙、监听状态、数据库进程和服务器负载。
• 出现重复连接请求或重传： 与客户端时间戳、TCP 建连测试和服务端日志对照，判断是否存在丢包或服务端响应延迟。
• TCP 建连正常，但查询阶段变慢： 转向数据库执行和应用等待分析，避免继续只检查网络。

若确需调整防火墙或白名单，先保存当前规则和变更记录，确认影响对象仅为目标端口及预期来源，并准备恢复原规则的方法。每次只调整一项，立即验证连接和业务；若影响扩大或验证失败，应按保存的记录回滚。

6. 对照服务器资源和数据库连接状态

若多个客户端在相近时间变慢，或客户端路径和 TCP 测试基本正常，应检查数据库服务器在故障时段的资源情况。Linux 可使用：

uptime
vmstat 1 10
ss -lnt

uptime 展示系统负载情况；vmstat 可观察运行队列、内存和等待情况；ss 可查看监听端口。输出需要结合服务器配置、历史基线和业务负载解释。单凭负载数字较高，不能确定 CPU 是根因；也不能把不同规格、不同时间的主机数据直接比较。

结合已有监控和数据库诊断信息，重点对照：

• CPU 使用与运行队列是否在故障时段变化；
• 是否出现内存压力或磁盘等待；
• 数据库连接数、活动会话及连接错误是否变化；
• 数据库进程是否正常运行，监听地址和端口是否符合预期；
• 客户端请求到达时，服务端是否及时建立连接并响应。

如果服务器资源明显紧张，应继续区分数据库查询负载、其他进程占用和资源等待。进程重启或数据库配置变更可能影响业务，不应作为第一步试错；操作前应确认权限、影响范围、维护条件和恢复方案。

7. 把数据库执行耗时与应用排队分开

TCP 建连正常但应用依然慢时，将一次请求拆成几个阶段：获取连接、发送 SQL、等待数据库执行、接收结果、应用后续处理。阶段耗时有助于区分问题位置：

• 等待连接池变长，数据库查询本身正常： 检查活动连接、空闲连接、等待队列、连接归还情况和应用并发排队。
• 数据库端查询耗时也变长： 检查慢查询、锁等待、活动会话及执行计划变化。
• 建连或查询发生多次重试： 对照应用超时设置、重试次数和服务端日志。重试可能放大单次失败造成的用户等待，但不能单凭重试就确认网络丢包。
• 数据库各阶段耗时正常，应用总响应仍变长： 检查接收结果后的应用处理和其他等待环节。

还应确认应用是否在每次请求中重新解析主机名或新建连接。对于复用长连接的应用，DNS 更可能影响新连接建立，而不是已经建立连接后的每条 SQL 请求。数据库状态查询和权限要求因数据库类型、版本而异，应先确认实际环境，再使用对应的只读监控方式；不要直接运行来源不明的诊断语句或修改语句。

根据证据定位后，按原条件验证恢复

修复应针对已有证据支持的环节：解析错误时核对并修正解析配置；白名单与实际来源不匹配时，按数据库实际看到的客户端源 IP 调整受控规则；路径异常时，提交两端同时间段的目标、源地址和测试记录供网络运维核查；服务端资源、数据库执行或应用连接池异常时，则针对已确认的资源和等待阶段处理。

修复后使用与故障时相同的客户端、数据库主机名、端口和测试方法复测，至少确认：

1. 主机名解析到预期地址；
2. TCP 连接能够稳定建立，且没有新增异常超时；
3. 应用获取连接、执行查询和总响应等分段耗时，回到该环境自身的正常范围；
4. 业务高峰或相近负载时复测后，结果仍符合预期。

测试环境、时间、方法和样本数量不同，结果不宜直接比较；一次成功也不能证明间歇性问题已经消失。后续可持续观察连接超时、TCP 重试、数据库连接数、查询耗时和应用连接池等待。若问题复发，保留客户端与服务端同一时间段的日志、解析结果、路由信息和连接测试记录，再按同一顺序复查，避免仅凭一个现象反复修改白名单、防火墙或数据库配置。