DNS 记录已变更但业务仍访问旧地址：从缓存链路到灰度切换的排查实践
## 适用场景 线上服务切换负载均衡、迁移 API 网关或故障切流后，权威 DNS 已显示新 IP，但仍有一部分客户端持续访问旧地址。常见表现包括：请求间歇超时、少量用户仍命中已下线机房、发布后错误率在一个较长窗口内缓慢回落。 本文以 `api.example.com` 从 `203.0.113.10` 切换到 `
Tag
#网络
包含这个标签的文章。
Linux conntrack 表满导致偶发网络超时：从现场确认到容量治理的排查实践
## 适用场景 业务运行在 Linux 主机、Docker 或 Kubernetes 节点上，经过 NAT、iptables/nftables 防火墙或四层负载均衡转发。某个时段开始出现 API 偶发超时、DNS 请求失败、容器无法访问外部服务，但主机 CPU、内存和带宽看起来都正常；重启网络或重启节点后短暂恢复。
Kubernetes 内部域名间歇解析超时：CoreDNS 缓存与上游 DNS 的排查实践
## 适用场景 集群中的应用偶发报出 `lookup xxx on 10.96.0.10:53: i/o timeout`、`SERVFAIL` 或连接外部服务失败；重试后又恢复。故障通常集中在业务高峰，Pod 重建、扩容或切换节点后更明显。本文适用于使用 CoreDNS 作为集群 DNS，且 CoreDNS 需要转
Linux 网卡 RX 队列和软中断堆积导致丢包的排查与治理实践
## 适用场景 线上服务出现间歇性超时、请求延迟抖动、连接偶发重置，但应用日志没有明显报错，CPU 总使用率也不高。进一步观察会发现某几颗 CPU 的 `si` 软中断占用很高，网卡统计里存在 `rx_dropped`、`rx_missed_errors` 或 ring buffer 溢出。这类问题常见于高并发网关、
Linux TCP accept 队列溢出导致连接超时的排查与治理实践
## 适用场景 这篇文章适用于线上服务出现“偶发连接超时、重试后成功、服务 CPU 不高但新连接建立慢”的问题，尤其是 Nginx、网关、Java/Python Web 服务、RPC 服务或四层代理在流量突增时出现以下现象： - 客户端报 `connection timed out`、`connect timeou
Linux conntrack 表满导致连接超时的排查与治理实践
## 适用场景 本文适用于 Linux 主机、NAT 网关、Docker 宿主机、Kubernetes Node 或开启防火墙规则的服务器。当业务出现偶发连接超时、DNS 查询失败、服务间调用间歇性失败，而 CPU、内存、磁盘都看起来正常时，可以把 conntrack 连接跟踪表作为重点排查对象。 典型环境包括：