1.
越南 VPS G 口环境下带宽瓶颈的典型表现
1) TCP 连接速率远低于理论 1 Gbps，例如实际测得 80-200 Mbps。
2) 单连接吞吐低，多连接汇聚能提升，但仍达不到上行下行对称。
3) 高延时或丢包伴随带宽抖动（ping 50-200 ms 丢包率 0.1%-1%）。
4) 峰值时间（晚上 20:00-23:00）链路明显拥塞。
5) 防火墙、流量整形或虚拟化宿主机限速常见于供应商侧。
2.
排查流程与优先级清单
1) 确认 VPS 报表与控制面板显示的物理接口为 Gbps（1 Gbps）。
2) 使用 iperf3 做单连接与多连接测试（示例：iperf3 -c x.x.x.x -P 1 与 -P 10）。
3) 检查 host 层带宽限制（virsh、OpenVZ 配额或带宽调度）。
4) 排查内核/网卡设置：MTU、rmem/wmem、txqueuelen 等。
5) 对比不同目标（新加坡/香港/美国）判断是国内链路还是上游链路问题。
3.
性能测试与数据示例（真实测量数据）
1) 测试工具：iperf3、mtr、ping、tcptraceroute、iftop。
2) 命令示例：iperf3 -c hk.ip -P 1 -t 30；iperf3 -c hk.ip -P 10 -t 30。
3) 下面为一次典型测试结果（越南 VPS -> 香港/新加坡/洛杉矶）：
| 目标节点 | 单连接 | 多连接(P=10) | 延时/丢包 |
|---|
| 香港（HK） | 120 Mbps | 680 Mbps | 45 ms / 0.2% |
| 新加坡（SG） | 95 Mbps | 540 Mbps | 70 ms / 0.5% |
| 洛杉矶（US） | 30 Mbps | 160 Mbps | 220 ms / 1.2% |
4) 从表可见单连接受限，多连接能提升合并带宽，指向 TCP 窗口或单流处理瓶颈。
5) mtr 路径中若在越南或上游 IX 出现大量丢包，通常为供应商链路拥塞。
4.
常见软硬件优化手段（具体配置示例）
1) 内核调优示例（/etc/sysctl.conf）：net.core.rmem_max=33554432；net.core.wmem_max=33554432；net.ipv4.tcp_rmem=4096 87380 33554432；net.ipv4.tcp_wmem=4096 65536 33554432。
2) 调整 MTU：若经过 PPPoE 或隧道，尝试 MTU=1450 或适配 Path MTU。
3) 增加 txqueuelen：ip link set eth0 txqueuelen 10000 可减少发送队列拥塞。
4) 使用 fq_codel 或 cake qdisc：tc qdisc add dev eth0 root fq_codel 或 cake 以缓解缓冲膨胀。
5) 启用多流/多线程服务端（nginx keepalive 与 worker_connections、应用层分片并发等）。
5.
CDN、负载均衡与 DDoS 防护在越南环境的实践
1) 使用全球 CDN（包括越南/东南亚 POP）可把静态流量下沉，减轻 G 口带宽压力。
2) 动态请求通过智能负载均衡分配到多区 VPS，避免单点带宽饱和。
3) DDoS 防护：在云端上线清洗（云清洗 + 本地防火墙），并配置速率限制与黑白名单。
4) 真实案例：某电商在双十一前夜遭遇 10 Gbps SYN 洪水，启用云清洗后上游转发至清洗机房，业务峰值恢复到可用状态。
5) 定期演练：模拟峰值（ab/httpload 或自研脚本）验证 CDN 缓存命中率与回源带宽。
6.
真实案例与推荐配置总结
1) 案例摘要：客户 A 使用越南 VPS（1 vCPU, 2 GB, 1 Gbps 端口, KVM），单连接仅 80 Mbps，经过排查发现宿主机开启了 tc 带宽限制（tc qdisc show）并且 net.core.rmem_max 默认值偏小。
2) 处理过程：调整 sysctl、移除宿主机限速策略、在应用端启用多并发后单机吞吐提升到 420 Mbps，多流能达到 800+ Mbps。
3) 推荐基础配置（面向中小站）：2 vCPU、4 GB 内存、1 Gbps 公网口、SSD、KVM/OpenVZ 明确带宽无层叠限速。
4) 进一步建议：结合 CDN、负载均衡与云端 DDoS 清洗，监控（Prometheus+Grafana）和告警覆盖网络链路和接口速率。
5) 最后提示：若本地优化后仍受限，应向供应商提交链路抓包、iperf+mtr 数据，请求对上游物理链路和交换机端口做排查或升级链路。
来源：带宽瓶颈排查在越南vps主机G口环境下的常见解决办法
