看公开介绍是安卓不行但是 ios 可以，不知道苹果那边有什么硬件 bug 还是 0day 到现在还没修复

apple tv 现在没必要前置一个梯子了吧

200 大概只能海鲜市场了。op 对硬路由是不是有什么误解，硬件转发确实能很便宜还做到网速很快，可是梯子他是软件转发，包括 QoS 这些功能也一样，便宜的路由开 QoS 纯纯减速。而且那些路由本身性能弱内存小跑自带的服务都很勉强了，你还加个梯子那就更容易造成不稳定了，买回去天天断流用的也不舒服。

目前我知道的能跑满千兆最便宜的就是 MTK filogic 820 系列了，再往便宜的选有一些能带得动梯子但是只能跑 10-100M 左右（看加密算法）但稳定的路由可选，但还是建议一步到位吧

可能是优先级原因，看看 qci ？但在空闲基站应该不会有很大区别才对，现在 ip 又不漫游回归属地了，理论上没差

@JensenQian b 站的 8k 视频/HDR/杜比视界有特殊判定规则的，规则不适用于普通视频，具体来说 8k 视频不提供 avc 格式，只提供 hevc 和 av1 然后对电脑配置会有判定，即不是所有配置都能切出这类特殊视频，可以找 4k 及以下的规律。

@feikaras 在我这是默认 hevc 的...我的电脑甚至支持硬解 av1 。不知道 b 站有啥神奇的判定方法，设备不同还能不一样（毕竟我这边支持 AV1 ，但同样默认提供 hevc ）。

软解怎么不会发热，b 站那点码率另说，就说 4k60hz/120hz ，码率上个 30+Mbps ，hevc 和 av1 ，哪部手机可以保持流畅且长时间软解的？手机根本解不了那么多热量。软解是很吃 cpu 的，手机的工况并不适合长时间的 cpu 高负载。我电脑软解那 cpu 要上 100+W ，相比起硬解几瓦的功耗，你说为什么会发热？当年 720p 和如今 4k 的数据量根本不是一个维度的，而 cpu 在相同功耗下，提升的性能一直是有限的。

回到 720p 低码率视频软解，确实不怎么发热，但如果是硬解，手机直接就是凉的。你拉功耗看，依然能差出一倍多的。

@echo1937 不可能有政策禁止这么做，不然早就起舆论了，而且于情于理都不该禁止。但其实托管式貌似并不能规避审查，阿里云这些貌似是将审查做在 http/https 链接上的，你只要在他们的服务器上解密了，他们就会查一遍。只能说这样保证了内部确实不会复用文件。

另外不就事论事，除了「政策禁止」，还有「指导意见」，这玩意就灵活多了，而且大部分神奇规定都属于这个类型。

举个例子：浏览器黑名单。国内的大一点的浏览器从某个时间点开始，都内置黑名单，防止你不小心访问「违反相关法律法规」的网站而犯法。你很难说这其中没有「意见指导」。但是国内小众浏览器、国外入华的大众浏览器如 Safari 都没内置这个黑名单，他们一样的合法的。外企的产品在这一部分是有相对大的操作空间的。

b 站连浏览器端默认的都是 hevc ，你是如何「确定」 ios 端是 av1 的（移动端无法选择编码，不存在默认一说只存在强制）？我希望你出示抓包的证据，不然鉴定为纯 yy 、造谣。评论全都在输出情绪，根本没人给出证据。

再说了，其实 b 站的 av1 码率只比 hevc 低一点点，在浏览器端上。

还有就是，b 站的码率大小和编码效率没有 [任何] 联系。在浏览器端上，b 站的 avc 画质就是最好的，在浏览器端，hevc 和 av1 的码率普遍在 avc 的 25%-50%之间，中位数我体感是在 30%上下，这种码率下客观上你截静止帧比对画质就不可能和 avc 一样好。尽管 b 站一直坚称他们做了各种各样的优化和评估，让画质「看不出区别」。（但总得来说，b 站的优化确实可圈可点，除非仔细的去观察一些容易露馅欠码的地方，平时看视频确实是「看不出区别」，算是作出了取舍）。保留高码率 avc 应该是迫于之前自己承诺的码率，以及确实有一部分用户对高画质有追求，算是提供一个选项，反正正常用户现在默认 hevc 了，电脑端就算解不了也调软解/av1 ，根本不给 avc 。

我一直强调是「在浏览器端上」，因为在以前，浏览器端上的 hevc 码率是高于移动端的！我不清楚现在是否还保持了这个规则。b 站的理由是手机屏幕小，更不容易看出差别。

综上所述，b 站想要降本增效，完全可以继续降低移动端甚至是浏览器端的 hevc 画质（事实上已经干过好几回了，不同时期的平均码率是不一样的），而无需坑害你手机电池。b 站开弹幕自古以来发热就很严重...那个弹幕功能很耗电的，这又是另外一回事了。我不相信 b 站在 ios 端（对不支持 av1 硬解的设备）用 av1 解码。

国内有秒传，必不加密的（或者全局加密，密钥在云盘运营者手上，没啥用）。
国外网盘对内操作透明，无法证明他加密了或者不加密，我觉得是不加密的（可以应用去重算法）
对象存储服务商对内操作也透明，底层说不定一样去重呢

@xiaokangz 这里指的是对用户的数据加密，不同用户不同密钥。不是传输加密。现在国内基本上都是 https 了，传输已经是安全的了。也不是那种「全局加密」，虽然加密了，但任何人都能随便解密，只能说有作用但不大...

这真的很草台班子，降本增效是吧，隔壁新加坡阿里云还没修完呢

国内的机子挂梯子+反代一条龙，自己打隧道解决

或者百度网盘/阿里云盘等国内网盘咯，国外网盘回国肯定是慢的

实现不同，具体就去看计网和具体实现咯。找 gpt 去看定义就知道了

至于效果，只能说网络都能抽象和解耦和的，理论上确实能实现相同的效果，只是难度、效率和稳定性的问题

上下行对称？有这种好事？坐等小白鼠先试

@pierce4963 对，所以我说广义上我们说的路由翻墙，你要实现：按照设备 mac 或者内网 ip 实现透明代理，大陆 ip 不走你的 v2ray 提升性能和网速，实现自动更新各项配置和 ip 表。这些在 v2ray 中都不自带，你不能通过启动脚本来简单运行。

尽管理论上你写复杂脚本是可以的，但是这个脚本没有现成的，我很欢迎你写一个并开源。当你干完这些活，你会发现你实际上你把 merlin-clash 干的事情重新造了一遍，只是你的核心是 v2ray 而不是 clash ，不知道我这么说你能不能理解。你要结合上下文来回答，而不是跟 gpt 一样仅按照上一个回答的东西回复。

我也强调了：如果单纯是在路由器上开个 http 端口转发就算翻墙的话，那没有任何意义，随便挂一台手机都能实现这个功能。路由器翻墙最重要的是「无感」的体验，而不是找半天 http 全局代理在哪开，开完发现有些 app 并不按照全局代理走导致根本无法翻墙。暴力全局转发给 v2ray 后导致的性能问题我不用过多赘述了吧，现在性能最强的路由也不过只能跑千兆，跟硬件转发随随便便上 2.5G/5G 还是差很远。

@pierce4963 有没有一种可能，软件中心的 merlin-clash 也是闭源的，你把 koolcenter 给排了，又拿同样闭源的插件跑说不过去吧。所以你只能重新造轮子。

说句难听的，那客服还没 op 专业呢，大概率连 bl 是什么都不知道。这种现象普遍出现于软件、硬件和运营商类的客服中，简直对牛弹琴，唯一的办法就是一直上升工单直到懂行的高级客户经理/工程师对接

@pierce4963 这可能不是「一丁点计算机知识」，你是不是没有教过「朋友们」电脑知识。绝大部分不是计算机专业的，一定完成不了上述操作。

况且也没你说的这么简单，最基本的需求：按照设备 mac 或者内网 ip 实现透明代理，大陆 ip 不走你的 v2ray 提升性能和网速，实现自动更新各项配置和 ip 表。你又要配置多少东西？就开一个梯子我不如在自己设备里开 clash

再况且 koolshare 固件覆盖的比梅林固件全，对于现在性价比最高的（要我推荐我会推荐的）天选和小旋风 pro wifi6 版，你会怎么做？

@rogerchan16 有的，移动是推 v6 最积极的运营商了。但其实 v4 的路由更好，v6 主要出口在上海，延迟大

广移拉万物这可不是说着玩的。晚高峰单线程瞬间 200+M ，不是那种慢慢增长的速度，但非高峰期单线程也就 300+M 了到不了 500M （话说回来，移动这边好多 cdn 都拉不到这个数），多线程没测过，但千兆不是梦。

天威那边走联通，有些 pccw 的 ip 会绕路，绕路就慢