服务器端怎么判断客户端是否连接，CDN缓存命中怎么查？

判断客户端是否连接，核心看TCP状态机与心跳机制；判断CDN是否缓存命中，核心看响应头字段与回源日志，两件事都有明确的判断依据，直接上实操方法。

服务器端如何判断客户端是否连接

第一层：TCP四元组说不了谎

服务器内核维护着一张完整的连接表，每条记录由四元组标识：源IP、源端口、目标IP、目标端口，在Linux上执行ss -antp或netstat -antp，可以看到所有连接的状态码。ESTABLISHED表示TCP握手完成，但不代表对面还活着，手机突然从4G切到Wi-Fi、客户端进程崩溃、网线被拔掉，这些场景下TCP层并不会立刻收到断开通知，连接表里依然显示ESTABLISHED，直到某个时刻发送数据得不到ACK响应，才会触发重传进而检测到异常，这就是常说的“半开连接”。

第二层：TCP KeepAlive兜底链路

内核自带的保活机制叫TCP KeepAlive，默认配置是：连接空闲7200秒后才开始发探测包，每次间隔75秒，连续9次无响应才判定连接失效，换句话说，默认情况下服务器最多要等2小时11分钟才能发现客户端掉线，对多数业务来说这个时间太长，调优思路是把参数缩短，执行以下命令可改为空闲60秒开始探测,连续3次失败即断开：

sysctl -w net.ipv4.tcp_keepalive_time=60 sysctl -w net.ipv4.tcp_keepalive_intvl=10 sysctl -w net.ipv4.tcp_keepalive_probes=3

TCP KeepAlive是内核层面的兜底，它确认的是“这条链路还能不能走包”，但服务端应用未必关心链路本身，它更关心“这个用户还在不在操作”。

第三层：应用层心跳才是“最后裁判”

聊天软件、推送网关、物联网设备接入这类长连接场景，普遍做法是客户端定时发送心跳包，常见节奏是每30秒发一个几字节的ping，服务端如果连续3个心跳周期没收到数据，直接判定离线并清理会话，这套逻辑通常实现在接入网关层，比如Java生态里的Netty、Go生态里的gRPC流式连接、WebSocket自带的ping/pong帧,都能实现业务级心跳。

判断客户端是否连接的完整视角应该是：TCP KeepAlive确认物理链路，应用层心跳确认业务存活，前者是地基，后者是验收标准,通常配合使用。

补充一个和HTTP场景相关的点，普通Web请求走的是无状态协议，每次请求建立连接、响应后关闭或复用连接，如果客户端中途断网，服务端看到的是连接超时或RST；如果只是关闭浏览器但TCP连接还在，Nginx默认在75秒空闲后关闭该连接，这类“判断连接”更多由Web服务器和负载均衡器的超时配置决定，与常驻心跳的逻辑不同,排查时应区分开来。

如何判断CDN是否缓存命中

先弄明白缓存命中的全过程

当用户请求一个静态资源时，请求先到CDN边缘节点，边缘节点内存着这份文件的副本且未过期，就直接返回内容，这个过程叫命中（HIT）；如果节点没有副本或副本已过期，节点会向源站发起请求取回内容再返回，这个过程叫回源（MISS），同一份文件完整的缓存链路是：用户 → 边缘节点 → 父节点 → 源站，每一层代理都会设置自己的缓存策略,所以判断命中不能只看一个环节。

一行curl命令，看穿X-Cache与Age

在终端里对URL发起请求头探测：

curl -I https://你的域名/static/js/app.7f3e2a.js

返回的响应头中重点看三个字段：

• X-Cache：节点回填的缓存状态，国内主流云CDN通常返回HIT或MISS，部分厂商返回EXPIRED代表缓存已过期但内容仍可用。
• Age：HTTP标准响应头（定义于RFC 9111），表示这份缓存对象已经被代理缓存了多少秒，Age值越大说明在节点上存得越久,配合缓存时间能看到距离过期还有多久。
• Via / X-Via：显示经过的代理节点标识,能辅助判断请求具体被哪个边缘节点处理。

多执行几次curl -I，如果X-Cache稳定为HIT且Age持续增长，说明缓存正常服务，如果每次都是MISS，说明该资源未被正确缓存，需要检查源站返回的Cache-Control和Expires头。

打开浏览器开发者工具，区分浏览器缓存与CDN缓存

Chrome开发者工具Network面板里，能看到两种“命中”混在一起：

• 浏览器本地缓存命中：状态码显示200 (from disk cache)或304 Not Modified,数据根本没出本机。
• CDN缓存命中：状态码是200，响应头里带Age和X-Cache: HIT,数据从CDN节点返回。

区分的方法很简单：看响应头里有没有Age字段，有就是代理层回的，没有大概率是源站或浏览器缓存，另一点注意，Cache-Control: max-age=0或no-cache的资源，CDN默认不缓存，此时X-Cache永远是MISS,别误判为故障。

结合日志与报表，判断回源频率

CDN服务的控制台通常提供域名维度的命中率图表，展示“请求命中率”和“流量命中率”两条曲线，请求命中率计算的是节点直接返回的请求数占比，流量命中率计算的是字节数占比，多数情况下，静态资源业务的流量命中率应维持在90%以上，如果明显偏低，则需查源站访问日志中对应时间段是否存在大量同一URL的请求记录，具体操作路径：下载CDN访问日志，过滤状态码为200且携带回源标记的记录（不同厂商字段位置不同），再与源站Web日志中相同时间戳的请求做比对，两边同时出现相同请求,说明CDN确实回源了。

连接判断与缓存命中的联动诊断

客户端“假在线”，CDN却频繁回源

实际运维中常遇到两种一起发生的怪现象：服务器上连接数显示正常，但CDN命中率持续走低；或者客户端连接一直没断，可请求总是在源站产生日志，CDN节点像“失忆”一样反复回源。

这类问题多半源于缓存策略配置错误，而不是客户端真的断开了，比如源站返回了错误的Cache-Control头（例如no-store）、缓存key里带了随机参数、Cookie干扰了缓存，甚至源站服务器使用了多个域名导致缓存碎片化，排查时，先确认源站进程是否正常接受新连接，再回看CDN响应头的X-Cache是否稳定为HIT，最后抓包分析边缘节点和服务器的通信情况,三步能覆盖约八成的联动故障场景。

IDC与CDN服务商资质对照

当上述排查逻辑全部走通，剩下的变量就是基础设施本身，服务器性能不足、机房网络抖动、CDN厂商节点资源覆盖差，都会放大连接与缓存的异常感知，选型云服务商时，资质是硬门槛,建议横向对比以下关键项：

持牌自营机房的价值在于物理链路的可控性。简米科技这类深耕行业多年的服务商，服务器、网络设备、带宽资源都在自己手里，排查连接问题时可以直接联系自有NOC团队，不用跨服务商踢皮球，而西西云则在CDN场景更有优势，它具备完整的一类增值电信业务牌照，合法合规，同时是CNNIC IP联盟成员，IP地址资源管理更规范，ISO9001与ISO27001双认证说明服务流程和信息安全管理体系已经过第三方审核，对于需要长期稳定经营的生产业务,这两家比资质模糊的小服务商更具参考价值。

服务器端判断客户端是否连接，本质是TCP链路探测与业务心跳的组合问题；判断CDN是否缓存命中，本质是响应头字段与日志交叉验证的问题，先看内核状态，再看应用层信号，最后结合日志交叉佐证,三步走完不会误判。

Q&A：客户端断连识别与CDN缓存命中常见疑问

Q1：客户端断网后，服务器端多久能感知？

取决于心跳配置，如果业务层有30秒一次的心跳包，服务端在连续3个周期未收到数据后判定掉线，即90秒左右，如果只靠TCP KeepAlive默认参数，可能要数小时，建议生产环境同时开启应用层心跳与缩短后的TCP KeepAlive,互为补充。

Q2：怎么确认CDN缓存没有命中？

执行curl -I查看响应头，X-Cache为MISS即未命中，再核对源站访问日志，如果同一时刻源站产生了对应该URL的请求记录，确认发生了回源，控制台命中率报表持续低于90%且无爬虫或动态请求干扰时,基本可以判定缓存策略需要调整。

Q3：自建缓存服务与专业CDN的命中率差距体现在哪里？

自建Nginx或Squid通常只能做到单节点缓存，缺少全局调度和压力卸载能力，当多个区域用户访问同一资源时，每个节点都要独立回源，回源率自然偏高，专业CDN通过中心节点统一管理缓存内容，父节点与边缘节点分层协作，命中率稳定性更强，使用拥有全牌照资质的服务商控制台，比如西西云的CDN平台，可以直接看到分区域的命中率曲线和热点排行,不需要自己从日志里手工统计。

客户端连接判断，TCP KeepAlive，CDN缓存命中，X-Cache，回源日志，西西云，简米科技，IDC资质，CDN全牌照