金砖国家弱网测试需基于真实探针数据定制参数，用tc命令在容器内配置netem、toxiproxy进程级毒化或adb+iptables真机注入，避免套用通用模板。
在金砖国家（BRICS）典型弱网环境下测试App网络稳定性时，需模拟高丢包、长延迟、低带宽的真实链路特征，不能仅依赖本地Network Link Conditioner或Chrome DevTools的通用预设。
确认目标弱网参数组合
先查清你要复现的具体国家-运营商场景：巴西Vivo 4G平均RTT 180ms+丢包率4.2%，南非MTN 3G下行峰值带宽仅1.3Mbps，印度Jio 4G上行抖动超60ms——这些数值必须从真实探针数据中获取，【直接套用网上流传的“金砖弱网模板”会导致压测结果完全失真】。
打开 https://www.netradar.io/brics 或本地部署的M-Lab数据看板，筛选“Country=India”+“AS=55836(Jio)”+“Protocol=TCP”，导出最近7天的RTT/Packet Loss/Throughput分位值（取P90而非平均值）。
用tc命令构建Linux容器级弱网规则
进入已部署App服务的Ubuntu 22.04容器内部（非宿主机），执行以下操作：
加载qdisc模块：modprobe sch_netem
在eth0网卡上启用netem队列：tc qdisc add dev eth0 root handle 1: netem
设置核心参数（以印度Jio场景为例）：tc qdisc change dev eth0 parent 1: netem delay 120ms 40ms distribution normal loss 3.8% 25% rate 1.1mbit。注意这里用rate限速而非bandwidth，因为tc对bandwidth的支持在内核5.4+才稳定；【漏掉distribution参数会使延迟分布变成固定值，无法模拟真实抖动】。
用Toxiproxy实现进程级可控弱网
方法一：Docker快速启动代理
docker run -d -p 8474:8474 --name toxiproxy shopify/toxiproxy
创建指向后端服务的毒化链路：curl -X POST http://localhost:8474/proxies -d '{"name":"api_jio","listen":"0.0.0.0:8081","upstream":"real-api:80"}'
注入印度弱网毒剂：curl -X POST http://localhost:8474/proxies/api_jio/toxics -d '{"type":"latency","attributes":{"latency":120,"jitter":40}} → curl -X POST http://localhost:8474/proxies/api_jio/toxics -d '{"type":"limit_data","attributes":{"bytes":1150000}} → curl -X POST http://localhost:8474/proxies/api_jio/toxics -d '{"type":"timeout","attributes":{"timeout":"500ms"}}
方法二：Go代码内嵌控制（适合CI流水线）
在测试脚本main.go里import "github.com/Shopify/toxiproxy/client"，初始化client后调用proxy.AddToxic("latency", "downstream", 1.0, toxic.ToxicAttributes{"latency": 120, "jitter": 40})，注意toxic type必须用小写字符串，大写会返回400错误。
Android真机侧动态注入弱网
第一步：在ADB连接的设备上启用adb shell root权限：adb root → adb remount
第二步：推送定制iptables规则脚本到/data/local/tmp/netem.sh，内容包含：iptables -A OUTPUT -p tcp --dport 443 -m statistic --mode random --probability 0.038 -j DROP（模拟丢包）→ iptables -A OUTPUT -p tcp --dport 443 -j DELAY --delay 120ms --delay-jitter 40ms（注意DELAY模块需提前insmod）
第三步：执行脚本并验证：adb shell sh /data/local/tmp/netem.sh → adb shell iptables -L OUTPUT -v 查看匹配包数量是否持续增长。若无增长，说明应用实际走的是UDP通道或使用了QUIC协议，需改用eBPF hook方式捕获socket层流量。
