下面是逐行注释版完整流程。所有命令块都可以整段复制进 SSH 执行（# 开头的注释不会被执行）。

AX6S + ImmortalWrt + PPPoE(30M/6M) SQM 完整配置流程

阶段 1｜环境确认

# 确认上网方式，PPPoE 才会走本流程；若返回 dhcp 说明光猫已拨号，参数需另调
uci show network.wan.proto

# 查看 PPPoE 拨号成功后生成的逻辑接口名，后续所有命令都以它为准
# 常见值：pppoe-wan（绝大多数情况）、wan（部分固件）
ifstatus wan | grep -i '"device"'

# 查看当前 SQM 配置，确认段名（命名段 sqm.wan 还是匿名段 sqm.@queue[0]）
# 这决定后续 uci set 命令的写法，ImmortalWrt 通常是 sqm.wan
uci show sqm

⚠️ 若接口名不是 pppoe-wan，请把下面所有 pppoe-wan 替换成实际值；ifb4pppoe-wan 也要同步改成 ifb4<你的接口名>。

阶段 2｜关闭硬件加速（最关键）

MT7622 内置 MediaTek PPE 硬件转发引擎，它会绕过内核 QoS，让 SQM 对部分或全部流量失效。这步不做，后面全白配。

# 关闭软件流量分载（SFO）
# 可选值：'0'=关闭  '1'=开启
# 说明：SQM 官方称可与 SFO 共存，但为排除干扰，这里一律关闭
uci set firewall.@defaults[0].flow_offloading='0'

# 关闭硬件流量分载（HFO）——必须关，这是 PPE 加速的总开关
# 可选值：'0'=关闭  '1'=开启
# 说明：开启后 SQM 对 99% 流量失效，且两者不可兼得
uci set firewall.@defaults[0].flow_offloading_hw='0'

# 保存防火墙配置
uci commit firewall

# 查 WED（无线以太网调度）的配置来源，决定下一步怎么关
cat /etc/modules.d/mt7915e 2>/dev/null
grep -rn "wed" /etc/modules.conf /etc/modules.d/ 2>/dev/null

根据上一条的输出二选一：

# 情况 A：输出里有 wed_enable=Y（写在 modules.d 里）→ 直接改那个文件
# 把 Y 改成 N 即可，Y=启用 WED，N=禁用 WED
sed -i 's/wed_enable=Y/wed_enable=N/' /etc/modules.d/mt7915e

# 情况 B：无输出（说明固件内核模块默认就是 Y）→ 在 modules.conf 里显式覆盖
# 追加一行模块参数，格式：options <模块名> <参数>=<值>
echo "options mt7915e wed_enable=N" >> /etc/modules.conf

# 开启 Packet Steering（数据包引导），让双核 A53 分摊网络中断负载
# 可选值：'0'=关闭  '1'=开启（所有 CPU）  '2'=部分
# 说明：AX6S 是双核，开着能降低 SQM 时的单核占用，纯收益
uci set network.@globals[0].packet_steering='1'
uci commit network

阶段 3｜断电重启 + 三项验证

# 软重启，让上面的配置生效
reboot

⚠️ 重启后必须拔掉电源，等 10 秒再插回去。

MT7622 的 PPE 表项在软重启后会残留（OpenWrt 已知 issue #19895），不断电清不干净，会导致 SQM 部分失效。

# 验证 1：WED 是否关闭
# 期望输出：N
# 可能值：Y=仍启用（需回到阶段 2 排查）  N=已禁用  （文件不存在=模块未加载，也算通过）
cat /sys/module/mt7915e/parameters/wed_enable

# 验证 2：PPE 是否还有卸载表项
# 期望输出：空
# 说明：有内容说明仍有流量走硬件加速，SQM 管不住这些流量
# 若 ppe0 目录不存在，试：cat /sys/kernel/debug/mtk_ppe/bind
# 两个都不存在 = 固件未启用 PPE，反而省心，直接进下一阶段
cat /sys/kernel/debug/ppe0/bind

# 验证 3：硬件分载确认关闭
# 期望输出：firewall.cfgxxxxxx.flow_offloading_hw='0'
uci show firewall.@defaults[0].flow_offloading_hw

🛑 只要 WED 仍显示 Y，就先停在这里，别往下走——多半是刷了闭源 MTK 驱动固件，需要换开源驱动的标准固件。

阶段 4｜基线测速（开 SQM 前的对照）

打开 https://www.waveform.com/tools/bufferbloat​ 测一次并截图保存。

重点记录三项：

• 实际下行速率 / 上行速率
• Loaded Latency（满载延迟增加）​ —— 预计几十到几百 ms

建议用有线测。WiFi 测会混入无线自身的延迟抖动，干扰判断。

阶段 5｜安装 SQM（已装可跳过）

# 更新软件源索引
opkg update

# luci-app-sqm  = LuCI 网页界面
# sqm-scripts   = SQM 核心脚本
# kmod-sched-cake = cake 队列算法内核模块（不装则无法选 cake）
opkg install luci-app-sqm sqm-scripts kmod-sched-cake

阶段 6｜写入完整配置（核心）

# ── 先删掉旧配置，避免参数残留 ──────────────────────────
uci -q delete sqm.wan          # -q 表示不存在时不报错
uci set sqm.wan=queue          # 创建名为 wan 的队列段（后续用 sqm.wan.xxx 引用）


# ── 基本设置 ────────────────────────────────────────────
# 是否启用此 SQM 实例
# 可选值：'0'=停用  '1'=启用
uci set sqm.wan.enabled='1'

# 限速作用在哪个接口上——必须是 PPPoE 逻辑接口，不能填物理口 eth0 或 br-lan
# 可选值：pppoe-wan / wan / 阶段1 查到的实际接口名
uci set sqm.wan.interface='pppoe-wan'

# 队列算法（排队规则）
# 可选值：
#   cake     = 功能最全，自带 per-IP 公平、ACK 过滤，首选
#   fq_codel = 更轻量，CPU 弱或带宽高时备选，约快 15%，但功能少
uci set sqm.wan.qdisc='cake'

# 队列设置脚本
# 可选值：
#   piece_of_cake.qos = 单队列 besteffort，不区分优先级，适合 99% 场景
#   layer_cake.qos    = 四档优先级（diffserv4），需配合 DSCP 打标使用
#   simple.qos        = 配 fq_codel 时用
uci set sqm.wan.script='piece_of_cake.qos'


# ── 链路层适配（决定速率计算精度）─────────────────────
# 物理链路类型
# 可选值：
#   ethernet = 以太网/VDSL2/光纤/网线入户，绝大多数选这个
#   atm      = ADSL/ADSL2+ 电话线入户
#   none     = 不补偿（不推荐）
uci set sqm.wan.linklayer='ethernet'

# 每包开销（字节）——PPPoE 环境的重点
# 可选值（中国 PPPoE 常用）：
#   46 = 国内 PPPoE 教程常见保守值（以太网22 + PPPoE8 + VLAN4 + 余量），当前用这个
#   34 = 无 VLAN 的 PPPoE（以太网22 + PPPoE8 + PTM4）
#   44 = 直接以太网/光纤/DOCSIS 通用保守值
#   26 = 纯 VDSL2 无 PPPoE
# 说明：宁可偏大不可偏小。偏大只损失零点几个 Mbps；
#       偏小会导致队列估算失真，满载时 bufferbloat 突然复现
uci set sqm.wan.overhead='46'

# 开启链路层高级选项（下面 tcMTU/tcTSIZE/tcMPU 才生效）
# 可选值：'0'=关闭  '1'=开启
uci set sqm.wan.linklayer_advanced='1'

# 队列的最大 MTU
# 可选值：1500（标准以太网）  2047（推荐，覆盖巨型帧/PPPoE 封装后超限场景）
# 说明：填太小会导致大包被错误补偿，建议 2047
uci set tcMTU=... 
uci set sqm.wan.tcMTU='2047'

# 时间槽大小
# 可选值：128（推荐）  64  1024（你的原值，偏大）
# 说明：影响速率计算的时间粒度，128 是社区推荐值
uci set sqm.wan.tcTSIZE='128'

# 最小包长补偿
# 可选值：64（DOCSIS/裸以太网）  68（VDSL2）  84（PPPoE/光纤，推荐）  96（ATM）
# 说明：小包的开销占比更高，补偿不足会导致小包速率被高估
uci set sqm.wan.tcMPU='84'

# 链路层补偿机制
# 可选值：default（推荐，用 tc_stab）  htb_private（仅实验用）
uci set sqm.wan.linklayer_adaptation_mechanism='default'


# ── 速率设置（最关键的两个数）────────────────────────
# 下载限速，单位 kbit/s
# 可选范围：实测下行最低值 × 70% ~ 95%
#   24000 = 28M 的 85%（保守起步）
#   25000 = 28M 的 89%（当前值，推荐）
#   26250 = 28M 的 94%（极限尝试）
# 说明：按实测**最低值**打折，不能用峰值。带宽波动到低于此值时 SQM 失效
uci set sqm.wan.download='25000'

# 上传限速，单位 kbit/s —— 本环境最重要的是它
# 可选范围：实测上行最低值 × 70% ~ 90%
#   5100 = 6M 的 85%（推荐，上行是瓶颈，要压得比下行更狠）
#   5400 = 6M 的 90%
#   4500 = 6M 的 75%（延迟仍不达标时再往下压）
# 说明：原值 6800 是按峰值设的，带宽掉到 6M 时 SQM 不再是瓶颈，必须改小
uci set sqm.wan.upload='5100'


# ── 队列高级选项 ────────────────────────────────────────
# 开启队列高级配置（下面的 squash / ECN 才生效）
# 可选值：'0'=关闭  '1'=开启
uci set sqm.wan.qdisc_advanced='1'

# 无视入站（下载）报文的 DSCP 标记
# 可选值：'0'=保留运营商标记  '1'=全部清零（推荐）
# 说明：运营商的 DSCP 不可信，保留反而可能被错误优先
uci set sqm.wan.squash_dscp='1'

# 入站方向忽略 DSCP（与上面配合，彻底重置优先级）
# 可选值：'0'  '1'=开启（推荐）
uci set sqm.wan.squash_ingress='1'

# 入站（下载）方向的 ECN 显式拥塞通知
# 可选值：ECN（推荐，通过标记而非丢包通知降速）  NOECN
# 说明：下载带宽相对宽裕，用 ECN 能减少丢包重传
uci set sqm.wan.ingress_ecn='ECN'

# 出站（上传）方向的 ECN
# 可选值：NOECN（本环境推荐）  ECN
# 说明：⚠️ 上行仅 6M 太窄，直接丢包腾位置比 ECN 标记更有效。
#       原值 ECN 是错的，必须改。带宽 >50M 时才建议开 ECN
uci set sqm.wan.egress_ecn='NOECN'


# ── 高级自定义参数（真正拉开差距的地方）────────────────
# 开启「非常高级」选项 —— 不设这个，下面两行字符串会被忽略
# 可选值：'0'=关闭（默认）  '1'=开启（必须）
# 说明：这是 LuCI 界面「Dangerous Configuration」区最下面的那个勾，
#       不开的话 tc 里会显示 no-ack-filter / triple-isolate
uci set sqm.wan.qdisc_really_really_advanced='1'

# 入站（下载）方向的 cake 参数
# 可填参数（空格分隔，按需组合）：
#   nat           = 让 cake 识别 NAT 后的内网 IP（必加）
#   dual-dsthost  = 按内网目标 IP 做公平队列，多设备互不抢（推荐）
#   ingress       = 更激进地整形入站流量（推荐）
#   diffserv4     = 启用四档优先级（换 layer_cake.qos 时才加）
#   memlimit 32Mb = 提高 cake 内存上限（千兆环境才需要）
# 说明：dual-dsthost 保证某人开 200 线程下载也抢不走别人的份额
uci set sqm.wan.iqdisc_opts='nat dual-dsthost ingress'

# 出站（上传）方向的 cake 参数
# 可填参数（空格分隔，按需组合）：
#   nat          = 识别 NAT 内网 IP（必加）
#   dual-srchost = 按内网源 IP 做公平队列（推荐）
#   ack-filter   = ⚠️ 本环境收益最大的开关，压缩冗余 ACK
#   diffserv4    = 四档优先级（配 layer_cake 时用）
# 说明：ack-filter 的作用——30M 下载时纯 ACK 回包约占上行 12%，
#       过滤掉后能省出带宽给真正的数据。上下行比 >4:1 时强烈建议开
uci set sqm.wan.eqdisc_opts='nat dual-srchost ack-filter'


# ── 日志 ────────────────────────────────────────────────
# 调试日志
# 可选值：'0'=关闭（日常用）  '1'=开启（排查故障时开，会刷大量日志）
uci set sqm.wan.debug_logging='0'

# 日志详细程度
# 可选值：0~10，5 为常规，排查时可设 8
uci set sqm.wan.verbosity='5'


# ── 保存并启动 ──────────────────────────────────────────
uci commit sqm                 # 写入 /etc/config/sqm
/etc/init.d/sqm enable         # 设为开机自启
/etc/init.d/sqm restart        # 重启服务使配置生效

💡 LuCI 界面提示：LuCI 对 iqdisc_opts / eqdisc_opts 支持不全，界面上可能显示为空或不匹配。一切以 tc -s qdisc 的实际输出为准。

阶段 7｜验证生效（两条都要跑）

# 查看上传方向的 cake
# 期望：bandwidth 5100Kbit ... dual-srchost nat ack-filter
# 关键检查点：
#   bandwidth 是否 = 你设的 5100
#   是否出现 ack-filter（出现 no-ack-filter 说明阶段 6 的高级选项没生效）
#   是否出现 dual-srchost（出现 triple-isolate 说明自定义参数没覆盖成功）
tc -s qdisc show dev pppoe-wan | head -1

# 查看下载方向的 cake —— ⚠️ 它在 ifb4 虚拟设备上，不在 pppoe-wan
# 期望：bandwidth 25000Kbit ... dual-dsthost nat ingress
# 若无任何输出 = 下载限速根本没创建，需检查接口名是否正确
tc -s qdisc show dev ifb4pppoe-wan | head -1

# 确认服务在运行
# 期望：running
/etc/init.d/sqm status

# 查看实时统计（可重复执行，观察 pk_delay / drops 变化）
# 重点看 Tin 0 里的：
#   pk_delay = 峰值排队延迟，应远小于 100ms
#   drops    = 丢包数，有少量属正常（这是主动限速的代价）
#   overlimits = 触发限速的包数，>0 说明 SQM 确实在工作
tc -s qdisc show dev pppoe-wan

# 2️⃣ 看下载方向的统计（同样重要）
tc -s qdisc show dev ifb4pppoe-wan

阶段 8｜复测与微调

回到 waveform.com 再测一次，与阶段 4 基线对比。

理想结果：​ Loaded Latency 从几十/几百 ms 降到 +0~+5ms，速度损失 10~15%（这是买延迟的钱）。

若延迟优秀但嫌慢 → 往上逼

# 每次只动 5%，改完必须重测
# 下载可填：25000 → 26250 → 27500（上限约 28M×95%=26600，别超）
uci set sqm.wan.download='26250'

# 上传可填：5100 → 5350 → 5600（上限约 6M×90%=5400，别超）
uci set sqm.wan.upload='5350'

uci commit sqm && /etc/init.d/sqm restart

🛑 判定规则：一旦 Loaded Latency 增加超过 10~15ms，立刻退回上一档。宁可牺牲速度换稳定延迟。

若延迟仍不达标 → 往下压

# 优先压上传，因为上行是瓶颈
# 可填：5100 → 4500 → 4000
uci set sqm.wan.upload='4500'
uci commit sqm && /etc/init.d/sqm restart

阶段 9｜进阶：应用优先级（可选）

piece_of_cake 只做公平分配，不区分应用。若想要「游戏 > 视频 > 下载」的优先级，才需要这一步。

30M 带宽下 AX6S 完全跑得动（MT7622 配 qosify 可扛 300M+）。

⚠️ qosify 与 SQM 二选一，不要同时开。

# 安装 qosify（eBPF 分类器 + cake）
opkg install qosify

# 上传带宽，支持 mbit/kbit 单位；可填 5mbit / 5100kbit
uci set qosify.wan.bandwidth_up='5mbit'

# 下载带宽；可填 24mbit / 24000kbit
uci set qosify.wan.bandwidth_down='24mbit'

# 启用 qosify
# 可选值：'0'=停用  '1'=启用
uci set qosify.wan.disabled='0'
uci commit qosify

# 自定义 DSCP 打标规则
# 语法：<匹配方式>:<目标> <DSCP值>
# 匹配方式可选：
#   dns:*.example.com  = 按域名匹配（推荐，能覆盖 CDN）
#   tcp:80 / tcp:8000-9000 = 按端口/端口段
#   udp:3478-3497      = UDP 端口段
#   192.168.1.100      = 按 IP
# DSCP 值可选（对应 diffserv4 四档）：
#   CS1 / LE   = Bulk 最低（下载、更新）
#   CS0        = Best Effort 默认
#   AF41       = Video 视频流中优先
#   CS5 / CS6  = Voice 最高（游戏、语音通话）
#   值前加 + 表示「仅当原标记为 0 时才覆盖」，如 +video
cat > /etc/qosify/01-my.conf <<'EOF'
# 游戏 / 语音（最高优先级）
dns:*.qos.gcloud.qq.com +video
udp:3478-3497 +video

# 视频流（中优先级）
dns:*.googlevideo.com AF41
dns:*.douyinvod.com AF41

# 下载 / 更新（最低优先级）
dns:*.steamcontent.com CS1
dns:*.windowsupdate.com CS1
EOF

# 重启生效
/etc/init.d/qosify restart

# 查看各优先级队列的流量分布，确认规则命中
qosify-status

切换到 qosify 时，需同步修改 SQM 配置：

uci set sqm.wan.script='layer_cake.qos'        # 改用四档优先级脚本
uci set sqm.wan.squash_dscp='0'                # 改 0，保留 qosify 打的标记
uci set sqm.wan.squash_ingress='0'             # 改 0，同上
uci set sqm.wan.iqdisc_opts='nat dual-dsthost ingress diffserv4'   # 加 diffserv4
uci set sqm.wan.eqdisc_opts='nat dual-srchost ack-filter diffserv4'
uci commit sqm && /etc/init.d/sqm restart

附录 A｜参数速查表

附录 B｜回滚（出问题恢复原状）

# 停止并禁用 SQM
/etc/init.d/sqm stop
/etc/init.d/sqm disable

# 恢复硬件加速，拿回满速
# 可选值：'1'=开启  '0'=关闭
uci set firewall.@defaults[0].flow_offloading_hw='1'
uci set firewall.@defaults[0].flow_offloading='1'
uci commit firewall

# 重启（同样建议断电重启）
reboot

附录 C｜故障速查

现在请执行阶段 6 的完整命令块，然后把阶段 7 两条 tc 命令的输出发我。​ 确认 ack-filter 出现、且 ifb4pppoe-wan 有输出后，再去 waveform 测速，把 Loaded Latency​ 告诉我，我判断 5100/25000 还要不要继续调。

—-满载测试—-

找到了，有专门的中文版 bufferbloat 测试站，而且完全免费、无需注册：

首选：https://bufferbloattest.org/zh

中文界面，测法跟 waveform 一样——先测空闲延迟，再分别给下载、上传施压，实时记录延迟尖峰和抖动，最后给 A+ / A / B / C​ 等级。判定标准：

但说句实话：对你这个环境，中文站未必比你”自己组合测”更准

原因很实在——这类海外 bufferbloat 站的服务器都在境外。虽然它测的是”延迟增加量”（loaded − idle）这种相对值，理论上能绕开跨洋基线高的问题，但一旦国际出口拥堵，增加量会被污染成虚高，容易误判成”SQM 没效果”。

而你只有 30M/6M，随便一个国内节点就能轻松跑满，根本不需要海外站。所以更推荐下面这套：

更准的方案：国内节点跑满 + 同时 ping 国内 DNS

第一步：电脑上打开国内测速站把带宽跑满（任选一个，都能轻松打满 30M）

• 中科大：https://test.ustc.edu.cn （librespeed，无广告，能看延迟+抖动）
• 南大：https://test.nju.edu.cn
• 测速网：https://www.speedtest.cn （三运营商节点多）

第二步：在测速跑的同时，在另一个窗口执行 ping

# Windows
ping -n 60 223.5.5.5

# macOS / Linux / 路由器
ping -c 60 223.5.5.5

ping 目标建议用 223.5.5.5（阿里 DNS）或 119.29.29.29（腾讯 DNS），国内节点响应快、不歧视 ICMP。

第三步：看最后的汇总行 min/avg/max/mdev

两个测法都做，交叉验证

1. 先跑 bufferbloattest.org/zh​ 拿个等级（图省事）
2. 再用 国内测速站 + ping 223.5.5.5​ 验一遍（更贴近你日常刷国内网站、打国内游戏的真实体验）

两次结果一致，就可以放心定稿这套 5100/25000 的参数了。

测之前记得：其他设备先别占网、优先用有线。然后把等级和 ping 的 min/avg/max/mdev 发我。

—-测试结果—-

执行 阶段 7｜验证生效（两条都要跑）

这次数据是满载状态下的，质量比上次高得多——可以下结论了。

数据解读：SQM 完全接管，两个方向都饱和了

上行 overlimits 超过 100%，是最好的信号——意味着每一个包几乎都经过整形，SQM 完全掌控了出口，运营商那侧的缓冲区根本没机会堆积。

一个漂亮的细节：ack-filter 在疯狂干活

上行 dropped 2000 看着吓人，但拆开看：

Tin 0 drops  =  498   ← 真实数据丢包
ack_drop     = 1502   ← ack-filter 主动滤掉的冗余 ACK
             = 2000  ✅ 完全对上

真实丢包只有 498 / 242318 = 0.21%，剩下 1502 个全是”反正要重发、丢了也没损失”的冗余确认包。这正是 6M 上行最需要的——省下来的带宽全给了真正的数据。这个开关你开对了。

下行丢包 721 / 210202 = 0.34%，同样极低。

结论：有富余，可以提速

延迟余量非常大（1.93ms / 80us，而 cake 的容忍线是 5ms），说明现在的限速设得偏保守，还有速度可以换回来。

建议往上提一档：

# 上行：6M 的 85% → 90%
uci set sqm.wan.upload='5400'

# 下行：28M 的 89% → 95%
uci set sqm.wan.download='26600'

uci commit sqm && /etc/init.d/sqm restart

⚠️ 前提：这两个数是按你实测的最低值（6M / 28M）算的。如果哪天带宽掉到 6M 以下，上行 5400 就会失效。你观察下这段时间带宽稳不稳，稳的话用这组；不稳就退回 5100/25000。

验证：跑满再 ping

改完后，在跑满带宽的同时​ ping，这是唯一可靠的判据：

# 电脑上开测速站把带宽跑满，同时在路由器执行
ping -c 60 223.5.5.5

看汇总行的 min/avg/max/mdev：

加完再 tc -s qdisc show dev pppoe-wan 看一眼，如果 pk_delay 涨到 3ms 以上但 ping 依然稳，就停在 5400/26600；如果 ping 开始飘，退回 5100/25000。

其实以你现在的数据（pk_delay 1.93ms / 80us），不开玩笑地说已经是很理想的状态了。​ 提速只是锦上添花——如果你平时打游戏、开视频会议已经不卡了，保持 5100/25000 不动也完全合理，稳定性优先于那 5% 的速度。