1. 概述与准备
目标：在台湾 CN2 VPS 上提升网络和应用响应、降低抖动与丢包。
前提：具有 root 或 sudo 权限；能够重启服务与安装软件。
准备工作：记录当前配置（命令：uname -a; lsb_release -a; free -m; df -h; sysctl -a > /root/sysctl.before）。
2. 网络层检测与基线测试
步骤：安装测试工具并测基线。
命令：apt/yum install -y iperf3 mtr curl traceroute；iperf3 -s（在远端）和 iperf3 -c
测试吞吐；mtr -rwzbc 100 <目标> 检测路径丢包与延迟；curl -s -w "%{time_starttransfer}\n" -o /dev/null http://your.domain 测量首字节时间。
记录：保存测试结果用于对比，识别是否为线路（CN2）问题或本地配置问题。
3. 启用并验证 BBR 拥塞控制（TCP）
目的：降低拥塞带来的延迟和重传。
操作（Debian/Ubuntu/CentOS7+）：编辑 /etc/sysctl.conf 并追加：
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
保存后运行 sysctl -p。
验证：lsmod | grep bbr 或 sysctl net.ipv4.tcp_congestion_control（返回 bbr），或 ss -t | awk '{print $1}' 不需变更；并用 iperf3 再次测量吞吐。
4. 内核与连接数调优
目标：处理高并发短连接场景。
建议配置（追加至 /etc/sysctl.conf）：
fs.file-max = 300000
net.core.somaxconn = 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
应用：sysctl -p。并在 /etc/security/limits.conf 添加：
* soft nofile 200000
* hard nofile 200000
重启服务或重新登录以生效 ulimit -n。
5. 磁盘 I/O 与内存优化
目标：降低磁盘延迟，增大缓存命中。
操作：检查磁盘调度器（cat /sys/block/sda/queue/scheduler），建议使用 noop 或 deadline（SSD 可用 noop）。
MySQL/MariaDB 调整：编辑 /etc/my.cnf 或 /etc/mysql/my.cnf，设置 innodb_buffer_pool_size = 60%-70% 内存（仅 DB 专用机）; innodb_flush_log_at_trx_commit=2（有数据丢失风险，权衡写性能）；innodb_io_capacity = 200-1000（根据盘子）。
PHP：启用 OPcache（php.ini 中设置 opcache.memory_consumption=256; opcache.validate_timestamps=0 用于生产，部署时慎用）。
6. Nginx 基础调优与 Keepalive
目标：提高并发处理与静态文件响应速度。
主要配置（nginx.conf）：
worker_processes auto;
worker_connections 10240;
keepalive_timeout 65;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
调整 accept_mutex off（在多核且连接多时常用）。重载 nginx：nginx -t && systemctl reload nginx。
7. Nginx 缓存（proxy_cache 与 fastcgi_cache）实战
目的：减少后端压力与响应时间。
配置示例（在 http{} 内）：
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=pcache:100m max_size=10g inactive=60m use_temp_path=off;
fastcgi_cache_path /var/cache/nginx/fcgi levels=1:2 keys_zone=fcache:200m max_size=20g inactive=30m;
在 server/location：
proxy_cache pcache;
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
fastcgi_cache fcache;
fastcgi_cache_key $scheme$request_method$host$request_uri;
并设置缓存控制头（add_header X-Cache $upstream_cache_status;）。
清理缓存：rm -rf /var/cache/nginx/* 或使用缓存管理脚本；更精细请用 purge 模块。
8. 应用层缓存：Redis 与页面缓存
场景：动态站点（CMS、API）推荐使用 Redis 作为对象缓存与会话存储。
安装：apt install redis-server；修改 /etc/redis/redis.conf 限制访问（bind 127.0.0.1）并设置 maxmemory 与 eviction policy（maxmemory 2gb; maxmemory-policy allkeys-lru）。
在 PHP/WordPress：安装 phpredis 或 Redis 插件，启用页面级缓存（短缓存+异步刷新）和对象缓存（缓存 DB 查询结果）。定期监控命中率：redis-cli info stats。
9. CDN 与地理就近策略（针对台湾）
说明：CN2 是优质回程，仍建议结合 CDN，尤其对静态资源、跨境访问使用。
步骤：选择在台北/新竹有节点的 CDN（Cloudflare、Fastly、阿里云 CDN 台湾节点等）；配置缓存规则（静态长期缓存、动态短缓存），并开启 HTTP/2/QUIC 在 CDN 端。
验证：curl -I 看响应头是否来自 CDN；用 mtr/traceroute 验证回源路径。
10. 监控、日志与回滚策略
监控项：CPU、内存、磁盘 I/O、网络延迟、丢包、应用响应时间、缓存命中率。
工具：Prometheus + Grafana、Netdata、cAdvisor（容器场景）、ELK 或 Loki+Promtail。
回滚：任何 sysctl 或服务改动先记录原值（sysctl -a > before），逐步改动并观察 30-60 分钟指标，若异常立即回退并重启相关服务。
11. 性能验证与持续优化流程
流程：1) A/B 改动（备份配置），2) 压力测试（ab/hey/wrk/iperf3），3) 监控指标对比，4) 小步上线并灰度，5) 自动化脚本化常用操作（Ansible/脚本）。
测试示例：wrk -t12 -c400 -d60s http://your.domain/path；观察 95/99 分位延迟与错误率；记录并纳入迭代清单。
12. 常见问题与安全注意
问题：启用 BBR 后 CPU 占用小幅上升、超大 file-max 需配合监控、opcache validate=0 会导致代码更新延迟。
安全：限制 Redis/Nginx 管理接口访问、TLS 配置使用强制安全密码套件、定期更新系统和内核补丁、对外暴露管理端口需用防火墙（ufw/iptables）与 fail2ban。
13. 问：如何快速验证 BBR 是否带来网络改进？
Q: 我如何判断启用 BBR 后在台湾 CN2 VPS 上是否真的改善？
A: 启用前后需做对比测试：使用 iperf3（长跑 60s）和 mtr（100 包）分别在相同时间段测试，记录吞吐、丢包率与平均/95/99 延迟；同时用应用层 wrk/ab 测试并比较 95/99 分位延迟与错误率。若延迟和丢包下降且吞吐提升即为正向改善。
14. 问：对于 WordPress/动态站点，推荐哪种缓存策略最优？
Q: 在台湾 CN2 VPS 上运行 WordPress，优先采用什么缓存组合？
A: 推荐“多层缓存”策略：1) CDN（静态资源）；2) Nginx fastcgi_cache 或 Varnish 做页面缓存（短缓存 + 异步刷新）；3) Redis 做对象缓存与会话；4) OPcache 提升 PHP 执行；并开启微缓存（例如 Nginx proxy_cache 10s）应对突发流量。
15. 问：做完这些优化后如何制定运维常规？
Q: 完成调优后，日常应该监控哪些指标与执行哪些定期任务？
A: 日常监控：网络延迟/丢包、带宽利用、95/99 响应延迟、缓存命中率、Redis 内存与命中、DB 锁与慢查询、磁盘 I/O、错误率。定期任务：每周检查日志与慢查询，每月回顾 sysctl 与内核升级影响，每次发布前在灰度环境验证缓存过期与回源逻辑。
来源：开发者视角看台湾vps cn2 云空间性能调优与缓存策略实践
