先给你梳理清楚这个问题的来龙去脉，结合你的观察和测试结果，拆解一下背后的原因：

首先得明确：https://xxx.googlevideo.com/generate_204这个接口是Google服务用来做网络连通性检测的，返回HTTP 204无内容状态码，主要用来判断网络是否正常、有没有强制门户跳转之类的，YouTube页面加载时会自动发起这类请求。

关于ERR_SSL_PROTOCOL_ERROR的真实含义 #

你用MITM代理发现服务器有时候直接断开请求，这刚好能解释Chrome的报错——这个提示其实是Chrome的“笼统报错”：当正向代理和Googlevideo服务器之间的TLS连接还没完成握手，或者连接中途被服务器主动切断时，Chrome没法精准判定具体是哪一步出了问题，就会抛出这个看起来像是SSL协议不兼容的错误，但实际根源是连接异常中断，而非协议本身不支持。

普通HTTP正向代理 vs SSL终止代理的差异 #

你猜测YouTube只支持SSL终止代理，这个方向是对的，但不是绝对的：

• 像TinyProxy这类默认的HTTP正向代理，只是做TCP流量转发，不会做SSL终止（也就是代理本身不解密HTTPS流量，只是把你的TLS握手请求原封不动传给目标服务器）。这种模式下，代理和Google服务器之间的连接稳定性完全依赖代理IP的可信度、代理的网络质量。
• 而SSL终止代理（比如你提到的微软防火墙L7 HTTPS代理）会先和你完成TLS握手，解密流量后再自己和Google建立新的HTTPS连接。相当于代理作为中间层，既能处理更多连接异常，而且Google看到的是代理的IP——企业级设备的IP通常更容易被Google信任，不容易触发限制。

为什么服务器会主动断开连接？ #

你观察到的服务器直接断开请求，大概率是Google的流量管控/反滥用机制在起作用：

• 很多公开的正向代理IP可能被Google标记为“非信任IP”或者“高风险IP”，当你开多个YouTube标签时，会频繁发起generate_204请求，Googlevideo服务器会主动断开连接来限制这类流量。
• 另外，普通HTTP正向代理在转发TLS握手包时，可能存在超时、丢包的情况，服务器也会直接切断连接，进而被Chrome识别为SSL协议错误。

为什么不用代理或用微软防火墙代理就没问题？ #

• 不用代理时，你的公网IP是正常的用户IP，Google不会轻易限制这类常规的连通性检测请求，连接稳定性自然高。
• 微软防火墙的代理要么是透明代理（相当于用你的真实IP访问，只是走防火墙转发），要么是SSL终止代理（用防火墙的企业级IP和Google通信），这两种情况都不会触发Google的限制机制，所以不会报错。

总结一下：你遇到的ERR_SSL_PROTOCOL_ERROR本质是Chrome对“代理与Googlevideo服务器连接异常中断”的模糊报错，核心原因是普通HTTP正向代理的IP可能被Google限制，或者代理本身的TLS转发能力不足，而非YouTube完全不支持非SSL终止代理。

备注：内容来源于stack exchange，提问作者drizin