酸酸乳服务部署说明++

Excerpt

前言更新：给自建酸酸/酸酸乳的朋友们的一些忠告及建议伸缩本篇说明仅供交流与学习使用，请勿作出任何违反国家法律的行为。本教程包含 Windows、Android、iOS、MacOS 端的酸酸乳客户...

觉得很有必要在这里说一些自建酸酸/酸酸乳所需要注意的事情、能提升VPS存活率的建议。

1. 不要认为加密/协议/混淆什么的随便都行

酸酸

1、加密请使用 AEAD 加密，包括以下几个

对于移动设备来说，ARM v8 以后的 CPU 使用aes-gcm的效率要高于chacha20，因此更推荐使用aes-256-gcm

2、混淆请使用plain，即不使用混淆插件，或者使用http\_simple

酸酸乳

能用plain没问题就用plain，当在plain情况下你察觉到网络有异样*，且你了解http_simple混淆参数的用途，再酌情使用http_simple

2. （科普）这些参数的意义是什么

有很多萌新同学直接拿一键脚本搭建的，脚本要求设置参数的时候也许萌新们就直接一路回车默认过去或者随便选了，殊不知这可能就正是VPS被Q的原因

混淆为什么不选tls

这是有可能导致被Q的一个首要原因，因此我也放到第一位来讲，也许细心的同学们也发现了上述推荐配置中的混淆这一行都加粗了，是的，这非常重要

前段时间我与其他人讨论的时候，就发现了一个共同点，那就是被Q的人大多数都使用了tls1.2_ticket_auth混淆；而一些混淆plain的人，即使还在使用老旧甚至过时的协议，却安然无恙

很有理由猜测 GFW 已经掌握了 tls 混淆的特征

让我更确信了我的猜测的是，后来询问我被Q相关问题的人，大多数都用的是搬瓦工后台自带酸酸乳，因为我从没有用过搬瓦工，我询问了他们后才知道，搬瓦工的酸酸乳是强制tls1.2_ticket_auth混淆，嗯，真不愧是 GFW 最佳合作伙伴（而且搬瓦工自带酸酸居然没有 AEAD 加密）

后来，推特上也有人指出

酸酸乳的tls凭据复用已经成为安全问题 不要用了

而且，就 tls 混淆原本的用途来说，tls 混淆只是为了突破部分地区的网络环境才有的 QoS 限制，一般情况下根本不需要使用
破娃酱也在文档里说的很明白，一切因使用混淆而产生的看似是网络加速了的效果都是因为绕过了限制，混淆实际上会减慢你的网络速度

并且，如果你并不明白http(s)协议的具体细节，没有这方面的计算机网络知识，那么也不要轻易使用http_simple之类的混淆；如果没有必要，也不要使用80和443端口；这些在 GFW 眼里很可能会成为一种明显的特征，会成为“为什么我的VPS好好的就被Q了”的直接原因

加密这块到底是怎么回事

简单的来说，我们若干年前使用的非 AEAD 加密，都存在被主动探测到的风险（这一块如果感兴趣想了解，可以自行谷歌 AEAD 加密的相关科普博文）

因此，如果是酸酸，强烈推荐使用之前提到的那5种 AEAD 加密，为了防止今后（可能的）来自 GFW 的主动探测

而酸酸乳，虽然目前并没有使用到 AEAD 加密，但是破娃酱在设计协议的时候已经考虑到了主动探测问题并且针对这块进行了设计，因此目前来说还是相对安全的，前提是你使用的是chain_a或auth_aes128_md5或auth_aes128_sha1协议

对于酸酸乳，chain_a是目前最佳的协议；chain_b虽然说更难以被识别，但是仍是一个测试版协议，并且实际使用发现丢包现象莫名十分严重，并不能用；至于酸酸乳乳那些chain_c/d/e/f，可以看看这里

之前提到的推荐配置中，酸酸乳的加密为none的原因是，auth_chain系列协议已经自带了RC4加密，针对 UDP 部分也有加密及长度混淆，因此一般情况下不需要再进行额外的加密；如果你觉得RC4加密有安全隐患，再套一层其他加密也可