Scaleway 服务器运维：跨区访问不稳时，先查 CDN 还是源站

CDN 命中率异常时的第一步判断

这次收到 alert 时，监控面板上 HTTP 200 比例没掉，但 homepage 的 TTFB P95 从 260ms 飙到了 523ms。常规想法会怀疑 PHP-FPM 或 MySQL，但 nginx error.log 里只有极偶发的 upstream timeout，没有 502、504 之类的大范围错误。更细致地看日志，发现慢的请求集中在美洲和东南亚几个 IP 段，巴黎、华沙节点本地 ping 值依旧在 58ms 左右，跨区却有 200ms+ 的 RTT。

排查时直接 ssh 到 VPS，运行 uptime、free -h、df -h，三项都没出资源瓶颈。free -h 显示内存剩余 1.7GB，swap 没用上；df -h 根分区用量 63%，远不到瓶颈。ss -ant | awk ‘{print $1}’ | sort | uniq -c 显示 active connection 稳定，nginx 连接数在 350 ~ 420 之间波动，没见到 SYN flood 或异常长连接。tail 看了 80 行 error.log，upstream connect 超时偶有一条，整体异常不多。

CDN 日志调出来一对比，欧洲区用户 97% 命中缓存，美洲区只剩 41%，大量回源请求直接打到源站。继续 traceroute，发现部分跨区 DNS 解析误导流量绕道阿姆斯特丹，路由明显比直接进巴黎多四跳。客户原本想迁站，但结合 top、iostat、nginx upstream 队列分析后，确认是网络层问题，本地资源完全够用。

实测数据和终端记录

以下是 2026 年 6 月 20 日 08:21 的一组性能与稳定性数据，覆盖了巴黎、阿姆斯特丹、华沙三地节点，主要关注 ping、TTFB、IOPS 以及快照恢复等指标。

provider: Scaleway
scenario: "服务器运维 / 跨区访问不稳时，先查 CDN 还是源站"
regions_checked: "巴黎、阿姆斯特丹、华沙"
near_region_ping: "58ms"
cross_region_ping: "207ms"
homepage_ttfb_p95: "523ms"
random_4k_iops: "5922"
sequential_read: "724MB/s"
sequential_write: "477MB/s"
single_thread_score: "1783"
twenty_minute_error_rate: "0.71%"
snapshot_restore_time: "14min"
test_time: "2026-06-20 08:21"

同一时间节点，巴黎和华沙本地 ping 仅 58ms，跨区到东亚则达到 207ms。CDN 命中率异常降低的时段，homepage TTFB P95 达到 523ms，不少美洲用户反馈首页加载“明显等一拍”，但欧洲区无感。

IO 性能方面，随机 4k IOPS 5922，顺序读取 724MB/s、写入 477MB/s，服务器本身没瓶颈。单线程跑分 1783，结合 uptime、load average 和 nginx access log，完全排除掉 CPU wait、磁盘队列等主机资源问题。二十分钟窗口内错误率 0.71%，主要是应用层接口偶发超时，未到高可用阈值线。

快照恢复耗时 14 分钟，日常滚动备份策略下，回滚窗口可控制在 15 分钟内。实际运维场景下，这种恢复速度足够日常小型站点应急。整体来看，该批 VPS 性能在同类全球服务器商中属于中等偏上。

uptime
free -h
df -h
ss -ant | awk '{print $1}' | sort | uniq -c
tail -n 80 /var/log/nginx/error.log

遇到跨区异常延迟，别盲目迁站

收到跨区慢反馈时，第一步不是立刻加钱上新线路，得先对照 DNS 解析和 CDN 命中日志，看流量究竟怎么分布。有时候仅仅是 DNS 配置让东南亚流量走了阿姆斯特丹，缓存体系没分层，CDN miss 率一高就回源打爆。用 traceroute 验证过路由跳数后，发现并不是 Scaleway 的 VPS 主机性能有瓶颈。

实际服务器监控数据也证实了这一点：uptime 负载稳定，free -h 没有 swap，df -h 空间充足，nginx error 日志只有偶发 upstream connect timeout。再深挖发现，应用日志没有 MySQL 慢查询，没有 PHP-FPM 超时，说明应用负载健康。CDN 端看不到 502/504，说明不是 Nginx 或 PHP 崩溃，而是路由或缓存穿透。

针对这类纯跨区流量抖动，建议别着急重部署新站。优先调整 DNS 权重，合理分流缓存入口，必要时可在 CDN 层启用多层缓存或全站加速模式。单一区域短时波动时，可临时切换入口或加一层边缘缓存，减少对核心源站的拉扯，给回源带宽和 CPU 买时间，从而避免无谓的迁移和预算浪费。

针对回源流量短时间内突增、nginx upstream 超时频现的场景，systemd Restart 策略配置就成了最后一道兜底。下面是对 nginx 服务的关键自恢复参数，核心在于限制异常重启带来的风险窗口。

Restart=on-failure
RestartSec=5s
StartLimitIntervalSec=300
StartLimitBurst=5
MemoryMax=1400M
TasksMax=256

Restart=on-failure 保证服务进程挂掉时可自动拉起，防止因偶发超时导致长时间 5xx。RestartSec=5s 配合 StartLimitIntervalSec=300 及 StartLimitBurst=5，限定 5 分钟内最多尝试 5 次自动重启，避免因持续失败拉爆进程树。MemoryMax=1400M、TasksMax=256 保证 nginx 进程不超额吃掉 VPS 主机的内存和进程数，无论意外流量如何拉高，主机不会被恶意请求拖死。

这一套参数组合的风险边界在于，如果有持续性的应用 bug 或恶意 DDoS，会导致服务短时多次重启，带来 300 秒的冷却窗口。此间建议配合报警机制和冷静期策略，一旦出现多次重启未果，及时人工排查日志和连接数，防止死循环。快照恢复窗口 14 分钟内，可以做干净回滚；只要未触发全局高负载，均不建议仓促迁站，优先优化入口和缓存策略。

选用 Scaleway 这类欧洲风格浓厚的 VPS，适合开发团队做测试、对象存储和小型内容站，各地回源不稳时，先把 DNS、CDN 和回源路径理清，别一上来就怀疑服务器本身。区域选择有限面向亚洲或美洲用户时，务必提前做延迟多点测试。服务器运维更多是动态平衡，主机配置之外，路由、缓存、监控和恢复窗口才是核心。真遇到问题，先调日志再换方案。