代理IP 链路上，HTTP/2 的流优先级还能作数吗

浏览器在一条连接上会同时跑好几条流，并给它们排出先后顺序：先传页面骨架，再传样式与关键脚本，图片往后排。这套安排在直连时能明显提速，但走代理IP 之后，到了服务端那一侧往往已经不是你排的那个顺序了。

浏览器排的顺序，中间层未必照着做

第一段：优先级是怎么表达的。每条流可以带一个权重，还能声明自己依赖另一条流，彼此连成一棵依赖树。权重高的先拿到带宽，被依赖的父级先传完，子级才开始动。这是一套相当精细的表达方式，理论上能准确描述谁先谁后。

第二段：为什么需要这么精细。在同一条连接上，多条流是真真正正共享带宽的。没有优先级，所有资源一起挤，首屏能不能快点渲染出来基本看运气。有了优先级，关键资源先到，页面就能更早显示出能用的样子，用户感受到的等待也就短了。

第三段：代理IP 链路上发生了什么。浏览器到转发层是一条连接，转发层到目标站点是另一条连接。浏览器把自己的依赖树告诉了转发层，可转发层在向目标站点建立连接时，未必会把这棵树原样重建。多数实现要么把依赖关系直接拉平，要么按自己的规则重新排序，有的干脆完全忽略权重。

怎么判断优先级有没有生效

最直接的办法是看时序。打开开发者面板的网络页，观察关键资源是不是真的排在前面；再对比走代理IP 与直连两种情况下的顺序是否一致。如果直连时顺序整齐、走了代理IP 之后变成一拥而上，那问题基本就出在中间层这一段。

还有一种更贴近实际的判断方式：不看顺序，看结果。首屏时间、可交互时间这两个指标在两种情况下差多少，比纠结依赖树有没有被保留更能说明问题。指标差不多，就不必为这件事折腾；指标差得明显，再去查顺序也不迟。

需要分清的是，权重和依赖关系并不是一回事。权重解决的是带宽不够时分给谁多一点，依赖关系解决的是谁必须等谁先完成。中间层即便保留了权重，也未必保留了依赖树，这两者被拆开处理是很常见的。

值得为此折腾吗

多数情况下不值得。优先级带来的收益本来就是优化级别的，链路通畅时体现得出来，链路本身就是瓶颈时几乎看不出差别。代理IP 链路上更值得先解决的是连接稳定性、出口延迟与带宽余量，这些是可用级别的问题，先解决它们收益大得多。

真正需要关注它的场景其实很窄：一是页面资源非常多且主次分明，二是链路带宽紧张到必须靠排队顺序来救。只有这两条同时成立，优先级的传递才值得当作一个正式排查项，否则它排在很多更基础的问题后面。

小结：流优先级是浏览器给同一条连接上的多条流排的顺序，用权重与依赖树表达。代理IP 链路把一条连接拆成两半，浏览器这一半的顺序能被保留，转发层到目标站点那一半则由中间层重新决定，依赖树多半被拉平。判断它值不值得查，看首屏与可交互时间的差距；差距不明显，就先把稳定性、延迟与带宽余量这三件更基础的事做扎实。