1.
准备与基线测量（先做这一步）
步骤：1) 登录到你在新加坡的云服务器（SSH）。2) 在本地和服务器两端各自做基线测试：在本地：ping -c 10 服务器IP；在服务器：ping -c 10 你的客户端IP或常用外网IP（8.8.8.8）。3) 记录平均延迟、丢包率。为什么：有基线才能判断是跨网段问题还是服务器本身问题。2.
网络连通性详细检查：ping、traceroute、mtr
步骤：1) 使用traceroute -n -w 2 <目标IP>（或Windows tracert）。2) 使用mtr -r -c 100 <目标IP>（Linux）获取每跳丢包和延迟分布。3) 解释：如果上游某一跳显示高丢包/抖动（如50ms及以上波动或丢包>1%），很可能是线路问题；若到数据中心最后几跳稳定，而应用仍慢，偏向应用瓶颈。3.
带宽/吞吐量测试：speedtest 与 iperf3
步骤：1) 在服务器上安装speedtest-cli并运行 speedtest-cli --server4.
DNS与域名解析延迟排查
步骤：1) 使用dig +trace yourdomain.com，dig +short yourdomain.com。2) 使用curl -I -s -w '%{time_namelookup} %{time_connect} %{time_starttransfer} %{time_total}\n' https://yourdomain.com 来分解各阶段耗时。3) 解释：若time_namelookup很高，检查DNS解析策略或启用DNS加速/云解析。5.
服务器资源检查（CPU/内存/磁盘）
步骤：1) top 或 htop 查看CPU和内存占用。2) free -m 查看内存/交换区；vmstat 1 5 观察中断等待（wa）。3) iostat -x 1 5 或 dstat 查看磁盘IOPS和延迟。解释：若CPU接近100%或磁盘await很高，说明是服务器资源瓶颈。6.
磁盘与IO进一步诊断
步骤：1) 用fio或dd做简单IO测试：dd if=/dev/zero of=/tmp/testfile bs=1M count=1024 conv=fdatasync 测速。2) 检查云盘类型（本地SSD、云SSD、共享盘）与IOPS配额。解决：升级磁盘类型或调整RAID/缓存策略。7.
网络包级诊断：tcpdump 与 tcptrace
步骤：1) 抓包：tcpdump -i eth0 host8.
应用层性能分析：NGINX/Apache/PHP/FPM 与 HTTP 时间线
步骤：1) 启用nginx stub_status或status模块查看并发和活跃连接。2) 用curl -w命令分解连接/下载时间（见第4节）。3) 检查PHP-FPM slowlog、worker数、max_children。若backend处理时间长，偏向应用瓶颈。9.
数据库性能检查（MySQL/Postgres）
步骤：1) 开启慢查询日志（MySQL：long_query_time=1），分析EXPLAIN输出。2) 检查索引缺失、全表扫描、锁等待（SHOW PROCESSLIST / pg_stat_activity）。3) 解决：添加索引、优化SQL、使用读写分离或缓存（Redis/Memcached）。10.
应用追踪与Profiling（一步步定位函数/查询）
步骤：1) 对PHP/Java/Node应用使用APM工具（Xdebug/Blackfire/NewRelic/Jaeger）。2) 捕获慢请求的调用链与耗时热点。3) 根据热点优化算法、减少同步调用、引入异步队列。11.
常见快速修复清单
步骤：1) 启用CDN加速静态资源。2) 开启gzip/HTTP2、调整KeepAlive。3) 增加应用缓存、减少数据库同步查询。4) 如证实线路问题，联系云厂商或BGP提供商申请线路优化或切换可用区。12.
使用第三方监测与Looking Glass
步骤：1) 使用RIPEstat/Looking Glass或云商的网络探针检查从全球到新加坡的路由。2) 使用Prometheus+Grafana持续监控延迟、丢包、应用耗时。3) 有数据可佐证时向云商提交工单，附上mtr/traceroute与抓包。13.
调优操作系统与TCP参数（谨慎修改）
步骤：1) 临时修改测试：sysctl -w net.core.somaxconn=1024 net.ipv4.tcp_fin_timeout=30 net.ipv4.tcp_tw_reuse=1。2) 调整后观察连接与延迟变化。注意：先在测试环境验证再写入/etc/sysctl.conf。14.
升级建议与长期架构改进
步骤：1) 若频繁遇到网络抖动，考虑多可用区多线路或混合云冗余。2) 对于全球访问，结合CDN、边缘缓存和跨区读写分离。3) 定期进行容量评估与压测（stress-ng、wrk、ab）。15.
问：如何快速判断是线路问题还是应用瓶颈？
答：先做分阶段测试：用ping/mtr/traceroute看网络延迟与丢包；用iperf3测带宽；用curl -w分解HTTP各阶段；在服务器测CPU/内存/iostat。若网络跳点出现高丢包或traceroute最后几跳异常，多半是线路问题；若网络稳定但响应的time_starttransfer或应用处理时间很长，则为应用瓶颈。
16.
问：如果发现是线路问题，下一步怎么做？
答：先收集证据（mtr/traceroute、抓包），联系云商或带宽提供商提交工单；同时可临时切换到备用线路、启用CDN或将关键服务迁移到另一可用区/区域；必要时申请提升带宽或更换网络类型（增强网络）。
17.
问：若是应用瓶颈，有哪些优先级最高的优化点？
答：优先级：1) 启用缓存（页面/片段/对象缓存）；2) 优化数据库（索引、慢查询）；3) 降低同步阻塞（异步队列、连接池）；4) 调整Web服务器与应用进程配置（worker数、keepalive）；5) 用APM找热点并有针对性重构。
