先把“晚上变慢”和“服务器坏了”分开
很多网站白天访问正常，一到晚上八九点就开始变慢，后台打开也卡，图片加载转圈，偶尔还会出现 502、504 或数据库连接超时。第一反应往往是“服务器是不是不行了”，但这类问题不一定是单点故障，更常见的是业务高峰、网络链路、连接数、数据库慢查询、缓存失效等因素叠在一起，把原本还够用的资源推到了临界点。
排查这种周期性变慢，关键不是马上升级配置，也不是只盯着 CPU 看，而是先确认现象是否稳定复现：是不是每天同一时间段出现，持续多久，哪些页面最慢，静态资源和动态接口是否都慢，只有部分地区慢还是全国都慢。把这些问题说清楚，后面的判断才不会跑偏。
如果只是偶发几分钟，可能是备份、爬虫、定时任务或上游链路波动；如果每天晚高峰持续一两个小时，就更像流量高峰叠加资源瓶颈。两者的处理方式完全不同，前者偏向定位异常任务，后者更需要容量评估和架构优化。
先看访问量，而不是先看配置
晚上变慢最常见的原因，是访问量在固定时间段上升。企业官网、资源站、活动页、下载站、电商页面、内容站，都可能在下班后、直播后、社群推广后迎来集中访问。访问量增加并不只意味着带宽变大，它还会让连接数、进程数、数据库查询、磁盘读写、缓存命中率同时发生变化。
建议先看 Nginx、Apache 或 CDN 访问日志，把慢的时间段和正常时间段做对比。重点观察请求量、状态码、热门 URL、来源 IP、User-Agent、图片和附件请求占比。如果某些大图、压缩包、接口或后台路径在晚高峰被反复请求，瓶颈可能并不在整台服务器，而在少数资源或少数业务入口。
还要区分真实用户和异常流量。很多站点晚间变慢，并不是用户突然增加，而是爬虫、采集器、扫描器在固定时间段集中访问。日志里如果看到大量相似路径、异常参数、无意义的 User-Agent，或者单个 IP 在短时间内请求几千次，就不能只按“正常业务增长”处理。
带宽满了，CPU 可能一点也不高
不少人判断服务器是否吃紧时只看 CPU，但网站变慢并不一定会让 CPU 飙高。如果瓶颈是公网带宽，CPU 可能很低，内存也没满，用户仍然会觉得页面加载很慢。典型表现是图片、CSS、JS、下载文件加载缓慢，首屏资源拖很久，测速时下载速度上不去。
排查带宽问题可以看云厂商监控里的公网出方向流量，也可以在服务器上观察网卡吞吐。关键是把带宽峰值和套餐上限放在一起看：如果晚高峰长期贴近上限，说明访问已经被出口带宽限制住了。这个时候继续优化 PHP 或数据库，效果可能不明显，因为数据根本发不出去。
带宽不足的处理方式要看流量结构。如果大部分是静态图片、脚本和附件，优先考虑压缩、WebP、缓存和 CDN；如果主要是动态接口响应，才需要继续往应用和数据库层看。对于需要稳定公网出口的站点，也可以考虑把静态资源和业务入口拆开，避免下载流量把正常页面访问一起拖慢。
连接数打满时，页面会“排队”
另一类常见问题是连接数或进程数达到上限。Web 服务、PHP-FPM、数据库连接池、反向代理都可能有自己的并发限制。晚高峰请求一多，新请求不能及时被处理，就会排队等待，用户看到的就是“页面一直转圈”。
这种情况下，CPU 不一定很高，因为大量请求不是在计算，而是在等待空闲进程、等待数据库连接、等待磁盘或网络返回。可以检查 Nginx 活跃连接数、PHP-FPM pool 状态、数据库连接数，以及应用日志中的超时记录。如果同一时间段出现大量 upstream timed out、connection refused、too many connections，就说明瓶颈已经不只是访问量，而是后端处理能力跟不上。
处理连接数问题不要只盲目调大参数。调大 worker、进程数和连接池之前，要先确认内存是否承受得住，数据库是否能接住更多并发。否则前端排队少了，数据库反而被打爆。更稳妥的做法是先限制异常请求、提高缓存命中率，再根据资源余量逐步调整并发参数。
数据库慢查询会放大晚高峰压力
网站白天正常、晚上变慢，也可能是数据库在高峰期被慢查询拖住。平时访问少时，一个查询慢 300 毫秒不明显；晚高峰并发上来后，慢查询会堆积连接，导致后续请求一起等待。用户看到的是整个网站变慢，但根因可能只在某几个查询、某个插件、某个搜索接口或某个后台统计功能。
排查数据库瓶颈时，要看慢查询日志、连接数、锁等待、临时表、磁盘 IO 和缓存命中率。WordPress、CMS、论坛和电商系统尤其要注意搜索、分类页、标签页、热门文章、统计插件、会员订单等功能，这些页面很容易在流量上来后把数据库压力放大。
如果慢查询集中在少数表或少数字段，可以考虑加索引、减少复杂排序、优化分页、关闭不必要的实时统计。如果是整站动态页面都频繁访问数据库，就要考虑页面缓存、对象缓存或把部分接口改成异步加载。数据库问题靠升级配置可以缓解，但不优化查询，后面还会反复出现。
缓存失效会让高峰期雪上加霜
缓存是晚高峰稳定性的关键。很多网站平时看起来没问题，是因为页面缓存、对象缓存或 CDN 命中率还可以；一旦缓存配置不当、缓存过期时间太短、后台频繁刷新缓存，晚高峰的请求就会直接打到源站和数据库。
最容易被忽略的是缓存同时失效。比如大量页面设置了相同过期时间，某个整点一起过期；或者发布内容后全站缓存被清空；又或者热门页面没有缓存，冷门页面反而缓存很好。这些都会让流量高峰期突然变成源站压力高峰。
排查时可以看 CDN 命中率、缓存响应头、源站请求量变化，以及缓存清理操作记录。对于内容站和企业官网，热门页面、图片、CSS、JS 应尽量让缓存稳定命中；后台、登录态、购物车、搜索等动态区域则要单独处理，不能简单全站一刀切。
地区性变慢要考虑链路和解析
如果晚上只有部分地区访问慢，服务器资源却很正常，就要考虑运营商链路、跨网访问、DNS 解析和 CDN 节点问题。比如电信用户正常、移动用户慢，或者南方正常、北方慢，这类现象往往不是源站内部性能问题。
可以从不同地区做 ping、traceroute、HTTP 首包时间和下载测速，观察慢在 DNS、建连、TLS 握手、首包还是资源下载阶段。DNS 解析到不同 IP、CDN 节点回源异常、运营商晚高峰拥塞，都可能造成“服务器没满但用户很慢”。
对于面向全国访问的网站，单一源站公网出口有时会受到地区链路影响。使用合适的 CDN、合理设置 DNS、减少跨区域回源，可以明显改善晚高峰体验。如果业务对稳定性要求更高，选服务器时也要关注线路质量、带宽类型和目标用户分布，而不只是看 CPU 核数。
一套更稳妥的排查顺序
遇到晚上访问变慢，可以按“现象确认、流量分析、资源监控、应用日志、数据库、缓存、链路”的顺序排查。先确认是不是固定时间段、哪些页面慢、哪些地区慢；再看访问日志和 CDN 报表，判断是否有真实流量增长或异常请求；随后看 CPU、内存、带宽、磁盘 IO、连接数和进程池状态。
如果基础资源有明显瓶颈，就先处理最接近上限的那一项；如果资源看起来都正常，就继续查应用日志、慢查询、缓存命中率和第三方接口。不要只凭一个指标下结论，尤其不要看到 CPU 低就认为服务器没问题，也不要看到访问慢就立刻加机器。
对中小企业网站来说，最实用的做法是先把监控和日志留好，再逐步优化。比如给 Web 服务、数据库、带宽、磁盘、CDN 命中率设置基础监控；把备份、统计、采集、同步任务错开高峰；对大文件和静态资源使用缓存；对异常 IP 做限速或拦截。需要更换或扩容服务器时，再结合实际瓶颈选择配置。像速维云这类云服务场景，评估时也应把线路、带宽、峰值流量和业务访问时段一起看，而不是只比较账面参数。
结语
网站晚上一变慢，表面看是“服务器性能不够”，实际可能是带宽、连接数、数据库、缓存、异常流量和地区链路共同作用。排查的核心不是先升级，而是先找到晚高峰和平时到底差在哪里。只要把日志、监控和访问路径串起来，很多问题都能定位到具体层级，后续无论是优化配置、加缓存、上 CDN，还是扩容服务器，都会更有依据。
