好棒啊！只要明确上行 2M 达标率一下就上去了呢 https://ws2.sinaimg.cn/large/62e721e4gw1et47itgo0hg200m00mglg.gif

很多用户就是觉得不会出事就随便搞搞咯，先不说协议的问题，就算是 koolshare 你看看有多少人根本不去官网下载，随便百度一个镜像就刷上去了，openwrt/LEDE 也一样啊，官网镜像多麻烦，可能连 luci 都没有，百度前几名说不定连 SS 都预装好，不就好棒棒？

想想之前有些开发者 xcode 随便下，数字签名都不看一眼（还是在 macos 上那么麻烦才能绕过略数字签名错误的情况下），就明白这个大环境了，还指望用户关心这些么 https://ws4.sinaimg.cn/bmiddle/62e721e4gw1et02g5wksrj200k00k3y9.jpg

@im8a #40 你这个情况给我的感觉是 *.googlevideo.com 都没有被转发。。。

@AnonymousAccout #48 在阿里云上 DROP 完，你本地还是要把 UDP 转发到阿里云上啊，这样相当于黑洞。其实我不该提这茬的，不如直接在本地黑洞来得简单。

@buddha #36

我感觉这次的问题可能是 Google 为了防止 ytb 视频下载，而限制了访问视频必须和访问网站同源。实际上我看了 QUIC SESSIONS LOG，UDP 没有污染（有 SESSION 中的证书保证）的情况下直连，返回 403。而不能 UDP 连接到目标（ no receive ）结果是 `QUIC_SESSION_CLOSED` 反而解决问题。

有没有人试一下在出口 VPS 处把 UDP 443 端口 OUTPUT DROP 掉？

我的观察是这样的：

1、UDP 连不上 *.googlevideo.com 是可以观看的，所以路由器处直接把相关链接 block 掉或者转发到黑洞也可以解决问题。

2、UDP 经过转发正确链接到目标也是可以观看的。

3、不经过转发的 UDP 直连无法观看。

4、我现在不确定这里起作用的 UDP 链接到底是不是 QUIC，因为 chrome 的 QUIC 监测标签中 QUIC SESSIONS 为空，但是 EVENTS 里边是有搜索结果的。

5、说手机开了 TCP+UDP 的朋友们注意一下 DNS，因为手机 SS TCP 是 http+Socks5 代理，支持远端解析网址，但 UDP 转发可不是这样。

@parametrix #65 不好意思，关 QUIC 是要在 chrome://flags/ 里边的

@skylancer #53

@paradoxs #62

我是观察到访问 ytb 的时候的确有新建的 UDP 链接才这么说的。默认开启 QUIC 只出现在新版本的 Chrome 里，而且如果使用 http proxy （比如浏览器插件 + SS ）浏览器应该也不会使用 QUIC，所以还需要类似于在路由器处转发的情况才会出现这种故障。当然我不完全确定，出问题的可以试一试 chrome://net-internals/#quic 中关闭 QUIC。

@skylancer #40 你看楼上也不是所有人都失败啊

听上去像是大内网的毛病？

@parametrix #31 对了，我说的这种情况是对于在路由器上透明的

让我来告诉你们为什么：因为你们这些用 SS 的只转发了 TCP，而 youtube 的视频应该是用了 QUIC 所以是 UDP https://ws4.sinaimg.cn/bmiddle/62e721e4gw1et02g5wksrj200k00k3y9.jpg

所以有错误提示么？ SS 是否也转发 UDP，是否启用 DNS 转发？代理是完全国外还是国内 ip 分流？

我个人的看法是，用过一段时间（一年吧）以后的笔记本，要提升性能：

清理风扇灰尘+重新上硅脂 >> 换 SSD > 加内存

当然，这些都是有效果的，第一项真的最重要。