确认 GCE 实例已启动并能通过公网 IP 访问;在 GCP 控制台检查防火墙规则,允许 ICMP、TCP 端口(如 5201/iperf3、80/443)出入流量;在实例内执行 sudo apt update && sudo apt install -y iperf3 mtr traceroute curl nginx(Debian/Ubuntu),并确保有 sudo 权限。
从客户机到 VPS:使用 ping -c 10
在测试端启动服务端:iperf3 -s -p 5201;在另一端做客户端测试:iperf3 -c
使用 traceroute -n <目标> 或 tcptraceroute <目标> 识别中间跃点与跨境网关(如经由 HK、JP、US);若看到某跳延迟激增,记录该 ASN 与地理位置,便于与 ISP 或云厂商沟通。
检查实例是否在私有子网并通过 NAT 网关出网;若使用 Cloud NAT,确认并发连接与端口映射限制;在 VPC > 网络服务中查看 egress 路径与出口 IP 是否符合预期。
确认内核版本 >=4.9,然后运行:sudo modprobe tcp_bbr;在 /etc/sysctl.d/99-sysctl.conf 添加 net.core.default_qdisc=fq 和 net.ipv4.tcp_congestion_control=bbr;sudo sysctl -p;用 sysctl net.ipv4.tcp_congestion_control 验证 bbr 已启。
检查 MTU:ip link show dev eth0;如跨境隧道需降低到 1400;设置 sysctl 如 net.core.rmem_max=16777216、net.core.wmem_max=16777216、net.ipv4.tcp_rmem/wmem 调整为合适值,并重启服务验证效果。
在 nginx.conf 中启用 keepalive_timeout、sendfile on、tcp_nopush on;启用 gzip 或 brotli,使用 HTTP/2:listen 443 ssl http2;配置缓存头 Cache-Control 和 ETag,减少跨境请求频率。
若目标是中国大陆用户,考虑在香港/新加坡/日本部署边缘或使用第三方 CDN(Cloudflare/阿里云 CDN/腾讯云 CDN),并启用缓存静态资源;对于 API 或动态内容,可搭建轻量反向代理节点(HK/SG)做流量中转。
部署监控(Prometheus + node_exporter / UptimeRobot),持续记录 RTT、丢包、吞吐与错误率;按小时/天对比不同时间窗口,识别峰值时段与路线抖动。
若延迟高或丢包:确认是否为 GCE 出口限速、VPC 流量配额、宿主机网络拥塞或对端路由问题;与 GCP 支持提供 traceroute 与 mtr 报告请求核查。
问题(问):如何快速判定问题出在 VPS 侧还是跨境链路?
回答:先在 VPS 本地 ping/loopback 与本地 LAN 测试,确认本机网络栈正常;再从多个外部地点(家宽、移动、海外 VPS)对 VPS 做 mtr/iperf3 测试;若不同来源到达 VPS 的延迟/丢包一致偏高,多为 VPS/云侧或到机房的上游链路问题;若只有特定来源受影响,通常是跨境 ISP 或对端路由问题。
问题(问):启用 BBR 后有哪些指标要观测?
回答:关注带宽利用率(iperf3 吞吐)、RTT 变化(ping/mtr)、重传率与 CPU 使用率;BBR 常会提高吞吐同时使 RTT 稍增或更稳定,若看到高重传或异常 RTT 波动需回退并逐项排查。
问题(问):面向中国大陆用户,最实用的跨境优化第一步是什么?
回答:第一步是把静态资源交给在中国或港澳有节点的 CDN,并开启压缩与缓存;同时在香港/新加坡布置反向代理做动态请求中转,这两步通常能显著降低首字节时间和丢包影响。