Hysteria2 Brutal：带宽怎么填，卡顿怎么查
我判断 Hysteria2 是否有用，先看目标任务能不能持续完成，再看传输速度。下载窗口跳出的峰值，不能替代网页交互、文件传输和共享网络的实际表现。
这一页没有现场测试记录，也不提供协议胜负表。我把原理和验证步骤拆开写。你可以据此检查自己的连接，但不能把这里的分析当成某条线路的性能承诺。
UDP为什么会拖后腿
Hysteria2 依赖 UDP 路径传输，Brutal 无法补出链路缺少的容量；我会先查路径是否可用，再判断带宽设置是否合适。
能连接不等于能持续传输
客户端显示连接建立，只说明相关握手已经完成。它没有替你验证长时间传输，也没有证明上传和下载都能承受持续负载。打开文字页面正常，传文件却停顿，这些现象可以同时出现。
我会让你把“连不上”和“传不动”分开记录。前者从握手日志、证书和 UDP 通路查起；后者还要考虑包长、发送负载、接收能力与分流。把两类问题混在同张截图里，调参就容易跑偏。
也别因为换个接入网络便恢复，就认定服务端毫无问题。接入网络变化可能同时改变路径、地址转换和可用容量。你得到的是排查线索，还不是责任结论。
丢包不能只看表面
丢包可能发生在不同位置。发送过量、途中排队、设备处理不及，都可能让接收端少收到数据。相似的表现，修复方向却未必相同。
因此，我不会从“UDP 有丢包”直接跳到“运营商针对这个协议”。你需要比较空闲与负载状态，确认问题是否跟随某个接入网络出现，再检查服务端有没有同步异常。缺少这些对照，判断只能停在猜测。
NAT 也要单独考虑。连接闲置后恢复使用才出问题，与持续下载期间停顿，是不同的触发条件。keepAlivePeriod 涉及保活安排，但调短间隔不是通用修复，也不能替代对断开原因的确认。
Brutal到底管哪段
Hysteria2 通过 QUIC 承载传输，Brutal 处理发送节奏与带宽目标；我不会把拥塞控制当成路由优化或物理线路升级。
把路径和算法拆开看
你可以把连接想成这样的过程：应用交出数据，客户端封装传输，数据经过接入网络与跨境路径，到服务端处理后再访问目标。任意环节出现限制，应用都有可能感到卡顿。
Brutal 参与其中的发送控制。它不负责决定海缆走向，也不负责替换拥塞的出口。协议参数能改变数据进入路径的方式，却不能让数据绕开所有瓶颈。
TLS 负责的事情也要与拥塞控制分开。握手、传输保护和发送速率不属于同个问题。证书配置错误时，提高 bandwidth 不会让握手恢复；路径容量不足时，更换证书也没有理由提高持续吞吐。
如果这些概念还混在一起，可以先读代理协议各自负责什么，再回来判断故障位于哪层。
标定是目标，不是承诺
理解 Brutal，我更愿意从“你告诉它多少可用带宽”入手，而不是把它理解成不断抢发数据的开关。填写的目标越偏离当前路径，后续判断就越容易失真。
丢失的数据需要补偿，补偿本身也会占用传输资源。发送负担增加，并不保证应用拿到的数据同步增加。当瓶颈已经拥挤，额外负载还可能让等待变长。
把 Brutal 简化成完全不读取反馈的恒速水泵，也不够准确。这一页不提供未经确认的阈值公式，更不从参数名称推断内部算法。你真正要验证的是：增加发送目标后，有效传输有没有改善，交互有没有恶化。
包长是另一条排查线
握手能完成，大文件却反复停住，包长相关问题应进入候选原因，但不能直接定案。小规模交互成功，不代表后续不同大小的数据都能顺利通过。
这里要分清路径能承载的包长，以及客户端配置字段实际控制的对象。quicSettings.mtu 这样的写法不能跨客户端照搬；字段存在与否、所在层级和取值含义，以官方说明为准。
我也不会把探测载荷长度直接当作配置答案。探测工具、封装方式与协议开销不同，机械套用换算口诀，很容易得到看似精确、实际不适用的值。
怎么比较才不误判
Hysteria2 的比较应固定任务与路径，把负载、丢包和交互表现分开记录；我不从单个峰值推断协议优劣或线路质量。
先写清楚你要解决什么
下载资料慢、网页打开迟缓、空闲后掉线，应当使用不同的验证任务。拿持续下载证明网页交互改善，或者拿握手成功证明文件传输正常，都缺少中间证据。
我建议在动配置前写下故障描述：什么操作触发、什么时候出现、停止操作后是否恢复。描述越具体，越容易判断修改有没有作用。只写“感觉不稳”，后面很难比较。
随后保留原配置与原始日志。日志可以删去认证信息和服务端地址，但别把报错前后的上下文也裁掉。只剩报错名称，常常看不出它是原因还是后续反应。
比较时别同时换条件
要比较 Brutal 与 BBR，应尽量保持客户端、服务端、目标任务及接入网络一致。切换控制方式时，还要确认程序确实采用了对应设置，而非只改了配置文件的文字。
如果你同时换节点、改包长、提高带宽，再观察到下载变顺，改善来源就无法拆开。这样的操作可以作为临时恢复办法，却不能用来证明某个参数有效。
网络条件也会自然波动。因此，某次传输的变化只能作为线索。换回原设置再观察，能帮助你区分参数影响与环境变化。没有可重复的方向，就先保留判断。
自己记录哪些现象
| 观察对象 | 可以记录什么 | 暂时不能推出什么 |
|---|---|---|
| 握手过程 | 完成、超时、证书报错 | 持续传输必然正常 |
| 文件传输 | 停顿位置、恢复条件 | 协议在其他路径也占优 |
| 网页交互 | 负载前后的等待变化 | 所有应用都会相同 |
| 共享网络 | 其他设备是否同时卡顿 | 问题必定位于服务端 |
| 空闲恢复 | 闲置后是否需要重连 | 保活参数就是根因 |
记录不必复杂，但要能对应修改。写下“降低下载目标后，文件仍能传完，网页等待减少”，比只记“更快了”有用。
人工丢包只能验证假设
tc netem 可以用于受控环境中的网络条件验证，但人工设置不能代表真实跨境路径。现实中的丢失、排队和容量变化，未必符合你设定的模式。
如果你有条件做这类验证，应让带宽限制与丢包条件分开变化，并观察应用任务。只制造丢包，再宣布某种算法适合所有拥塞环境，结论跨得太远。
没有受控环境，也可以做配置前后的任务对照。只是记录里应保留环境限制，不把个人连接上的现象扩大成协议定律。
配置该从哪里动
Hysteria2 调整应从现有可运行配置出发，区分服务端限制、客户端目标与系统队列；我建议保留原值，再逐项验证修改。
服务端先确认控制权
你使用机场订阅时，通常不能决定服务端如何处理带宽提示。因此，本地填了 up 和 down，不能据此确认整条连接已按你的想法工作。
自己管理服务端，则应核对监听、证书、认证与带宽配置之间的关系。服务尚未正常启动前，不要把窗口和缓冲参数当成排障入口。基础连接恢复后，再讨论发送策略。
ignoreClientBandwidth 尤其不能只凭名字判断。它会影响客户端带宽提示的处理与拥塞控制选择，不宜理解成“忽略提示后照服务端数字持续发送”。具体行为以所用程序的官方说明为准。
我不在这里附整套可复制配置。缺少版本、部署方式和链路条件，同份配置里每个值看似都有依据，组合起来却未必适合你的机器。
客户端从任务容量标定
up 与 down 应按客户端视角理解，并分别确认上传和下载方向。别把服务端出口容量、家中接入套餐和当前路径可用带宽当作同个东西。
带宽标定的起点，应来自目标路径能够持续承受的传输，而非套餐宣传值。你还要给同网络中的其他任务留出空间。独自下载时能承受的负载，未必适合边开会边传文件。
调整时先降低引发问题方向的目标，观察任务完成情况与交互变化。如果网页等待缩短，下载也能继续，就有理由怀疑原目标过高。这个结果仍需复查，不能凭单次改善确定全部原因。
客户端是否读取了配置同样重要。界面保存成功，不等于运行中的连接采用了新值。可以结合启动日志与连接日志确认；导入后被覆盖的设置，也要重新核对。
Linux缓冲别成组照抄
Linux 的收发缓冲、队列和应用处理能力属于不同环节。扩大缓冲可能改变排队行为，却不会增加跨境路径容量。缺少主机侧证据时，成组替换系统参数会让排障更乱。
我会先保留当前设置，查看传输期间是否出现本机处理异常，再决定是否调整。若修改后只是数据暂时堆得更多，交互等待反而增加，就不能把它记作优化成功。
fq 与 maxrate 涉及队列和发送安排。它们若与应用目标叠加，可能形成额外限制。排查时要核对方向、接口和作用位置，不能只把队列上限与客户端 down 作简单大小比较。
没有服务端管理权限的读者，可以跳过系统调参。把客户端现象与脱敏日志整理清楚，比照抄无法确认作用对象的命令更实际。
分流先确认命中了什么
分流排查应从故障应用开始。确认请求实际进入哪个策略、哪个节点，以及故障发生时规则是否按预期命中。规则文件写着某个策略，不代表运行连接必然经过它。
不要为了减少 UDP 就直接套用整段拒绝规则。按网络类型和端口匹配，影响范围可能超出故障应用。把相关流量挡掉后网页恢复，也不能证明原路径已经修好。
我更愿意缩小变化范围：保留正常任务，只调整有问题应用的去向，再检查对应日志。使用相关客户端，可以对照Clash Verge配置与分流检查，确认导入配置与实际运行状态。
卡顿时按什么顺序查
Hysteria2 故障应沿握手、持续传输和应用表现逐层缩小范围；我会先确认连接停在哪里，再决定降标定或更换路径。
带宽写高就会更快吗
不会。提高目标值，只是改变发送控制的输入，无法向路径申请额外容量。如果有效传输没有增加，网页和其他设备却更迟缓，这次修改就没有达到目的。
此时应恢复原值，或降低相关方向的目标再比较。不要因为峰值短暂抬高，就忽略长时间停顿。你要完成的是任务，不是让窗口里的速度跳得更大。
包长改小就能修好吗
也不能保证。包长调整只能验证相关假设。如果证书错误、认证失败或规则选错，修改包长不会触及原因。
握手正常而持续传输停住时，可以在其他条件固定的情况下检查包长相关设置。若修改有效，应换回原值复查；若没有差别，就保留记录，继续查带宽负载与接收端状态。
ping -M do -s 1400 这类探测也有前提。目标如何回应、当前系统如何处理探测，都影响解释。未收到回应不等于 Hysteria2 数据必然过不去，收到回应也不能证明持续传输没有其他限制。
丢包出现就换协议吗
我会先问丢包与什么现象同时出现。只在大负载下发生，和空闲时也持续异常，排查方向不同。降低目标后改善，与更换接入网络后改善，也提供不同线索。
换协议可以保留为对照，但要尽量保持其他条件。换完节点又换协议，恢复连接当然有价值，只是不能把原因全部归给协议。
日志应该从哪里读
从客户端发起连接开始，确认握手是否完成。失败时按具体报错检查证书、认证与 UDP 通路，不把超时直接写成线路受到封锁。已经完成握手，则转向应用请求与持续传输。
接着判断问题是否跟随负载。暂停大文件传输后，普通网页是否恢复？降低上传或下载目标后，现象有没有变化？这些观察有助于把负载相关问题与基础连接问题分开。
然后核对服务端与客户端是否同时出现异常。有管理权限就检查服务端日志；没有权限就整理客户端记录。持续超时可沿节点超时的逐步排查继续缩小范围。
每次修改后都保留结果，包含没有改善的尝试。不要把失败记录删掉，它能避免你反复走回同条路。
长期使用怎样留余地
Hysteria2 是否值得长期使用，应看常用任务与共享网络的持续表现；我建议保留可切换路径，不把协议名称当服务保证。
个人连接先求任务能完成
日常使用不必追求所有任务都经过同个节点。文件传输、网页交互和其他应用可以分别验证，再按实际需要安排分流。
我会保留能够持续完成任务的设置，而不是反复追逐短暂峰值。只要网络环境改变，原来合适的标定也应重新检查。更换接入网络后仍沿用旧值，容易把环境变化误认成客户端故障。
共享出口要看旁人的表现
同条路径上的其他任务，也应进入判断。你的文件下载顺畅，不能抵消同网络网页明显迟缓的代价。共享使用时，单个任务的吞吐并不是全部目标。
团队环境还涉及配置由谁修改、异常怎样恢复。能够回退、能够说明修改原因，比留下难以解释的参数组合更有价值。先明确容量管理，再谈拥塞控制偏好。
IEPL、IPLC 与 Brutal 解决的问题也不能混为一谈。理解线路类别，可以读IEPL与IPLC的差别。协议选择不能替代对实际路径和服务约定的了解。
带宽口径该参考哪里
参考当前接入网络到目标服务端的持续传输表现，并区分方向。其他目标上的下载速度，可以提供背景，不能直接当作这条路径的标定答案。
我不提供通用折算比例。路径可能变化，共享负载也会变化。起点保守、逐步调整，并同时看交互表现，比套用固定比例更容易解释。
大文件停住就认定包长吗
不能。包长只是候选原因，还应检查发送目标、客户端日志、服务端处理和应用本身。只有修改相关条件后现象稳定改变，判断才有进一步依据。
若某个文件来源停住，其他来源正常，还要保留目标服务差异这个方向。不要因为使用了 Hysteria2，就把所有应用故障归到 QUIC。
会影响同网络其他人吗
可能。尤其在发送目标超出可用容量时，你的传输负载可能增加共享路径的压力。但是否已经发生，需要观察其他任务在负载前后的变化。
出现影响就降低目标，并检查服务端容量管理。不能把其他人的卡顿当成自己配置生效的证明。
晚高峰还应继续调吗
如果不同时间表现差别明显，应记录同样任务的变化，再区分容量波动与固定配置问题。没有证据前，不要用更激进的标定去抵消所有晚高峰卡顿。
降低目标仍无法完成任务，可以比较替代路径。继续堆参数未必比保留可切换方案更省事。
服务端该忽略客户端带宽吗
这涉及服务端如何处理客户端提示，以及希望采用哪种控制方式，不能给所有部署同个答案。应先核对官方说明，再结合共享方式验证。
你没有服务端权限时，本地修改没有产生预期作用，也可能与服务端策略有关。此时应提供明确现象和脱敏日志，而不是继续提高目标值。
混淆能解决限速吗
不能作这样的保证。obfs 与发送容量不是同个维度，开启混淆不能证明路径会提供更多带宽，也不能保证流量不会被分类处理。
keepAlivePeriod 同样不能当作抗限速按钮。保活解决的是连接维护问题。我的做法是按症状确认修改对象：容量问题查负载，闲置断开查连接维护，规则问题查实际去向。每个修改都要有能复查的理由。