[Feature Request] 更详细的方案：非可信通路 与 可信通路（VMore and VLess），含 VLess 具体设计方案

[RPRX]

2020-07-17 更新：

[New Protocol] VLESS BETA：性能至上、可扩展性空前，目标是全场景终极协议。

2020-06-20 更新：

[New Protocol] VLESS ALPHA

---

经过在 v2ray/v2ray-core#2526 中的讨论，我告诉 @ActiveIce 应该重新开一个 issue，于是他在 v2ray/v2ray-core#2541 中描述了一个方案，但我觉得将 VMess 的实现解耦掉各种 HASH、加密部分并不容易，会增大难度、延长 VMess 2 的设计时间，尤其是可能会带来新的未知问题。所以，基于种种考虑，我更倾向于下一步分为专攻两个方向的两个协议。由于这和一个协议解决所有问题有根本区别，所以我开了这个 issue。

首先，我并不希望这是一轮大规模重构，那样太麻烦且设计周期很长。我倾向于这两个新协议就只是两个新协议而已，要能复用 v2ray 的现有架构、其它组件，也就是说基础架构无需做任何变动。

请允许我引入一些自己想出来的概念：

经过思考，我觉得我们对 v2ray 的使用可以分为两种情况，即 非可信通路 与 可信通路，而没有半可信通路。比如，一般来说内网可以算作可信通路，而公网则算作非可信通路，但这两种情况并不是绝对的，通路可以互相转化。我举个例子，公网虽然是非可信通路，但基于 TLS 后可以变为可信通路，而如果途经 CDN，则又变回非可信通路。内网若不受自己控制，则不应算作可信通路，而应算作非可信通路。

---

那么，非可信通路 与 可信通路，各对应一种协议：VMore and VLess（就这么命名吧）

具体而言，专用于非可信通路的 VMore 是含 AEAD 加密和其它改进的 强化版 VMess，注重安全。

而专用于可信通路的 VLess 是无需任何 HASH、加密等多余计算的 阉割版 VMess，注重性能。

同时，这两个协议都应该支持可无限扩展的混淆方案（改变流量时序特征），等下我会详细描述。

对于 VMore 的具体设计，我个人并没有太多想法，只是认为这应该是一个相对整体的安全方案，而且觉得这可能是一个长期工程。建议多参考一些其它地方已有的最佳实践（而不是闭门造车），以及参考 https://github.com/v2ray/discussion/issues/711

对于 VLess 的具体想法，其实我已经在 v2ray/v2ray-core#2526 中描述过了，只是现在不是非要基于 TLS，如内网用途，这也是我想出可信通路、通路转化那些概念的原因 —— 现在的定位更明确：专用于可信通路，性能 MAX。

由于去掉了各种 HASH、加密等多余计算部分、支持关闭混淆，VLess 的性能将会比现在的 VMess 更强（即使后者加密选 none）。但 VLess 并非完全不 Mess，相反地，它的混淆方案更强大：支持无限扩展、随机选择、每次请求随机选择。

---

下面我将详细说一下 VLess 的具体设计，我想我们现在就需要它（鉴于 VMore 一时半会儿出不来）。由于主要是阉割，实现起来不难，熟悉 VMess 代码的大佬应该很快就可以完成。

参考：https://www.v2fly.org/developer/protocols/vmess.html

但由于这个文档有些地方有歧义（如现混淆方案 Shake 的参数），我还看了 VMess 的部分代码。

因为是用于可信通路，所以是明文、去掉所有加密，也没有系统时间相差要求等。 保持无状态，保留鉴权、兼容现有的路由、统计、底层传输方式等，不另起炉灶。 为 TLS 穿墙准备了可无限扩展的混淆方案，但其它用途无需开启，也不占地方。

客户端：

1. 认证信息无需 HMAC，只留 UUID，不要 MD5、UTC 时间。

2. 指令部分去掉 AES-128-CFB 加密，只留响应认证、指令、端口、地址类型、地址，其它全部不要。

3. 配置文件中新增“混淆方案”选项（把现方案改成可扩展形式），默认 none 不开启，填 auto 是随机选择一种混淆方案，rand 是每次请求随机选择，shake 则是现方案（参数改为后面提到的随机值）。指令部分结尾添加一个1字节的“混淆方案名称长度”，如5，接着是混淆方案具体名称 shake。有混淆方案时，继续添加一个1字节的“附加数据长度”，如16，接着是一个16字节的随机值。

4. 数据部分为“标准格式”，且没有加密。是否混淆、混淆方案取决于配置文件。 不混淆时，数据部分不采用“标准格式”，即不分割为若干小块，同时也不需要小块校验。

服务端：

1. 配置文件中新增“是否必须混淆”选项，默认 false 不强制，填 true 则客户端必须选择一种混淆方案，否则断开连接。请求到达时，若服务端没有请求中的混淆方案或无法成功解除混淆，则断开连接。

2. 应答头部数据去掉 AES-128-CFB 加密，只留响应认证，不要选项、指令部分。

3. 应答头部数据结尾添加一个1字节的“混淆方案名称长度”...（结构与前文相同）

4. 实际应答数据同样为“标准格式”，且没有加密。是否混淆、混淆方案和客户端的请求一致。 不混淆时，数据部分不采用“标准格式”，即不分割为若干小块，同时也不需要小块校验。

可能：所有混淆相关结构均移至最前，当选择了混淆方案时，后面所有数据均参与混淆（包括头部）

---

这样一来和 trojan 相比有什么主要区别？

0. 理论上来说，不开混淆时，VLess + TLS 速度可以追平 trojan（那么 trojan 就很尴尬了） WS 的 Base64 编码会使数据量膨胀 33% 左右，所以要么压缩，要么推荐其它长连接方式
1. VLess 不强制 TLS，且可以复用 v2ray 已有的其它组件（路由、DNS、统计、API等），适用范围更广。
2. 有强大的可无限扩展的混淆方案，还支持随机选择、每次请求随机选择。
3. 可以插一层 WebSocket/H2/QUIC 等 v2ray 已有、将有的底层传输方式。
4. 服务端可以由 nginx 处理 tls 并路径分流。（trojan 只能由 nginx 的 stream 段预读取 sni 来转发）
5. 当 v2ray 出现了新的 TLS 指纹解决方案时，可以直接拿来用。https://github.com/v2ray/discussion/issues/706
6. 如果你觉得 CDN 是可信通路，那么可以套 CDN。
7. （并不是很重要）trojan 只支持 socks5，而 v2ray 支持多种入站方式。

欢迎提出改进意见，也希望项目组给予反馈。

[kslr]

请问V2开发者还收love@v2ray.com和v2ray@protonmail.com的邮件吗？我认为VMess 2更好。我设想的方案已经发往V2开发者邮箱。

不接收邮件，关于设计请直接issue

[okudayukiko]

请问V2开发者还收love@v2ray.com和v2ray@protonmail.com的邮件吗？我认为VMess 2更好。我设想的方案已经发往V2开发者邮箱。

不接收邮件，关于设计请直接issue

涉及隐私不方便开issue。

[kslr]

请问V2开发者还收love@v2ray.com和v2ray@protonmail.com的邮件吗？我认为VMess 2更好。我设想的方案已经发往V2开发者邮箱。

不接收邮件，关于设计请直接issue

涉及隐私不方便开issue。

你可以使用gpg加密，公钥可以在报告安全问题机找到。

[RPRX]

@okudayukiko

虽然你说的是 VMess V2，不过我说一下 VLess 中的做法，可以了解一下 v2ray/v2ray-core#2583

1、UUID使用ECDH交换（如X25519）且经常Rekey，不使用系统时间，如果时间错了就很麻烦。另外基于时间和HMAC-MD5的模式计算量大。

VLess 直接只用 UUID，不进行多余计算。有 TLS 等现代加密的情况下其实不会看出重复特征的。

2、TLS可选ECDHCurve、PreferServerCipher（默认为False）、PreferChaCha20（PreferChaCha20=true则使用ChaCha20-Poly1305->AES-GCM->AES-CBC。PreferChaCha20=false则使用AES-GCM->ChaCha20-Poly1305->AES-CBC。默认为false）选项。

这个就属于 V2Ray TLS 的事情了，与协议是解耦的。

3、制定QR Code和Share link标准。

我也是这么想的，必须有官方分享标准，不能像 VMess 一样混乱。

4、V2Ray手机App仍然不规范，许多App不支持SOCKS5+WS+TLS。V2RayNG也不支持SOCKS5+WS+TLS。

Socks5 有两次握手，不如用 VLess，0-RTT。

5、由客户端选择是否混淆和加密（不使用VMess加密则由TLS处理加密）。这一段信号会被加密传输。

混淆可以由客户端选择、服务端适配，但是加密必须双方提前约定，不然无法完美解耦。 加密和 TLS 不应该是二选一的，还可以都不选（内网）

[okudayukiko]

@okudayukiko

虽然你说的是 VMess V2，不过我说一下 VLess 中的做法，可以了解一下 v2ray/v2ray-core#2583

1、UUID使用ECDH交换（如X25519）且经常Rekey，不使用系统时间，如果时间错了就很麻烦。另外基于时间和HMAC-MD5的模式计算量大。

VLess 直接只用 UUID，不进行多余计算。有 TLS 等现代加密的情况下其实不会看出重复特征的。

2、TLS可选ECDHCurve、PreferServerCipher（默认为False）、PreferChaCha20（PreferChaCha20=true则使用ChaCha20-Poly1305->AES-GCM->AES-CBC。PreferChaCha20=false则使用AES-GCM->ChaCha20-Poly1305->AES-CBC。默认为false）选项。

这个就属于 V2Ray TLS 的事情了，与协议是解耦的。

3、制定QR Code和Share link标准。

我也是这么想的，必须有官方分享标准，不能像 VMess 一样混乱。

4、V2Ray手机App仍然不规范，许多App不支持SOCKS5+WS+TLS。V2RayNG也不支持SOCKS5+WS+TLS。

Socks5 有两次握手，不如用 VLess，0-RTT。

5、由客户端选择是否混淆和加密（不使用VMess加密则由TLS处理加密）。这一段信号会被加密传输。

混淆可以由客户端选择、服务端适配，但是加密必须双方提前约定，不然无法完美解耦。 加密和 TLS 不应该是二选一的，还可以都不选（内网）

制定两套协议太麻烦了，VMess V2由客户端选择是否用VMess混淆比较好。另外调用System time的做法，时间一错就很麻烦。AES-GCM只提供加密不提供混淆，现在用SS秒封端口。我也认为加密必须双方提前约定比较好，如果用VMess V2则服务端要求必须开启VMess加密（由客户端选择AES-128-GCM/AES-256-GCM/ChaCha20-Poly1305），如果用VMess V2-TLS则服务端允许关闭VMess加密。VMess v2不兼容VMess v1，但V2Ray服务器默认开启这两种协议保持兼容性（Kitsunebi Android有半年没更新了）。 另外目前Ubuntu、Debian收录了SS，但没收录V2Ray、ACME.SH。目前FreeBSD收录了V2Ray、ACME.SH。

[RPRX]

@okudayukiko

现在的情况是，VMessAEAD 已经出了，比原来的 VMess 更重，而且同样无法解耦掉混淆和加密。 VLess 也出了，目前是由客户端选择是否混淆的，服务端会自动适配。不选择混淆则一干二净。

加密的提前约定指的是不能有协商过程（服务端自动适配也是协商），要提前约定哪种算法。 这种方式不影响内层协议，承载什么都可以，说白了就是另一个 TLS。

当 VLess 有约定加密后，其实就是对 VMess 做了一轮重构：核心、混淆、加密，三者高度解耦。 但是否加密不应该是强制的，不是说必须加密或 TLS，应该还可以都不选，这才是人性化的设计。

VMess v2不兼容VMess v1，但V2Ray服务器默认开启这两种协议保持兼容性

这是很难做到的，还会带来安全性问题。

[okudayukiko]

另外混淆用的SHAKE128，我用openssl speed -evp sha256、openssl speed -evp blake2s、openssl speed -evp shake256发现shake256最慢，blake2s最快。

[RPRX]

@okudayukiko

感谢，之前还真没留意这方面，我有空也测试下性能。

[RPRX]

@okudayukiko

SHAKE-128 和 SHA-256 速度相近，所以 SHAKE-256 确实应该比 SHA-256 慢。

https://blake2.net/

初步决定新增 BLAKE3：

https://github.com/BLAKE3-team/BLAKE3

[RPRX]

我突然发现 VMess 原有的混淆真的只是”元数据“混淆，十分鸡肋，不知道存在的意义是什么。

[RPRX]

准确地说，VMess 原有的“元数据混淆”在 TLS 上除了降低性能外完全没有任何意义，不应该被留着。

[okudayukiko]

TLS能指定ECDH Curve和Cipher suite也有必要。我認為，TLS應該增加幾個選項：ECDHCurve、EnableAEADCiphers。 EnableAEADCiphers預設為true。若EnableAEADCiphers=0，則使用ECDHE-ECDSA(RSA)-AES-256-CBC-SHA384->ECDHE-ECDSA(RSA)-AES-128-CBC-SHA256->ECDHE-ECDSA(RSA)-AES-256-CBC-SHA1->ECDHE-ECDSA(RSA)-AES-128-CBC-SHA1->RSA-AES-256-CBC-SHA384->RSA-AES-128-CBC-SHA256->RSA-AES-256-CBC-SHA1->RSA-AES-128-CBC-SHA1。若EnableAEADCiphers=1，則使用ECDHE-ECDSA(RSA)-AES-256-GCM-SHA384->ECDHE-ECDSA(RSA)-CHACHA20-POLY1305-SHA256->ECDHE-ECDSA(RSA)-AES-128-GCM-SHA256->ECDHE-ECDSA(RSA)-AES-256-CBC-SHA384->ECDHE-ECDSA(RSA)-AES-128-CBC-SHA256->ECDHE-ECDSA(RSA)-AES-256-CBC-SHA1->ECDHE-ECDSA(RSA)-AES-128-CBC-SHA1->RSA-AES-256-GCM-SHA384->RSA-CHACHA20-POLY1305-SHA256>RSA-AES-128-GCM-SHA256->RSA-AES-256-CBC-SHA384->RSA-AES-128-CBC->SHA256->RSA-AES-256-CBC-SHA1->RSA-AES-128-CBC-SHA1。OpenSSL預設握手是ECDHE-ECDSA->ECDHE-RSA，AES-256-GCM-SHA384->CHACHA20-POLY1305-SHA256->AES-128-GCM-SHA256。 我使用AnyConnect和Trojan發現，單核VPS使用AES-CBC-SHA2速度最快。在手機上使用TLS-AES-CBC-SHA2比TLS-AES-GCM-SHA2、TLS-CHACHA20-POLY1305-SHA256省電和快速。AEAD-SHA2要進行兩輪計算。單核VPS，Ubuntu 20.04，看YouTube 1080P時，VPS的CPU使用率就高達50%。 /etc/ocserv/ocserv.conf #Ocserv不使用AES-GCM的設定 tls-priorities = "NONE:+VERS-TLS1.0:+VERS-TLS1.1:+VERS-TLS1.2:+VERS-DTLS1.0:+VERS-DTLS1.2:+SIGN-ALL:+ECDHE-RSA:+ECDHE-ECDSA:+AES-128-CBC:+AES-256-CBC:+SHA1:+SHA256:+SHA384:+CURVE-SECP256R1" 在單核VPS和雙核VPS上，TLS-AEAD-SHA2性能都比TLS-AES-CBC-SHA2差，雖然表面上用openssl speed -evp aes-128-gcm和openssl speed -evp aes-128-cbc跑分，AES-GCM比AES-CBC快。

[okudayukiko]

@rprx ARM/AMD/Intel試圖用SHA指令集解決SHA慢的問題。當年就是靠AES指令集才能從RC4、3DES成功過渡到AES。 另外低端VPS（便宜的單核/雙核VPS）和手機（當然Android/iOS）用AEAD加密都耗電和性能低下，看HD Video只能用TLS-AES-CBC-SHA2。包括WireGuard的ChaCha20-Poly1305-Blake2s也是，速度慢，在手機使用很耗電。

[hyxxsfwy]

@rprx ARM/AMD/Intel試圖用SHA指令集解決SHA慢的問題。當年就是靠AES指令集才能從RC4、3DES成功過渡到AES。 另外低端VPS（便宜的單核/雙核VPS）和手機（當然Android/iOS）用AEAD加密都耗電和性能低下，看HD Video只能用TLS-AES-CBC-SHA2。包括WireGuard的ChaCha20-Poly1305-Blake2s也是，速度慢，在手機使用很耗電。

AES Golang Encryption Performance Benchmarks

据我所知，此類 BenchMark 的結論都是 AES-GCM 遠比 AES-CBC-HMAC 高效。從實際使用經驗看，AWS Lightsail 1C 1G 的低端 VPS 做测试服务器，server 配置为 Nginx + TLS1.3，多台客户端 vps 使用 wget 同时下载，协商的加密套件为 TLS_AES_256_GCM_SHA384。结果可以輕鬆跑滿 AWS 服务器 1Gbps 的出口帶寬，服务端 Nginx 进程 CPU 占用不超过 20%。加密方式根本不是速度的瓶頸。

所以，要麽請給出您的詳細評測方式和數據，要麽請停止这种无意义的宣傳推廣老舊加密套件的行爲，否則我有理由懷疑你的動機。

[okudayukiko]

@rprx ARM/AMD/Intel試圖用SHA指令集解決SHA慢的問題。當年就是靠AES指令集才能從RC4、3DES成功過渡到AES。 另外低端VPS（便宜的單核/雙核VPS）和手機（當然Android/iOS）用AEAD加密都耗電和性能低下，看HD Video只能用TLS-AES-CBC-SHA2。包括WireGuard的ChaCha20-Poly1305-Blake2s也是，速度慢，在手機使用很耗電。

AES Golang Encryption Performance Benchmarks

据我所知，此類 BenchMark 的結論都是 AES-GCM 遠比 AES-CBC-HMAC 高效。從實際使用經驗看，AWS Lightsail 1C 1G 的低端 VPS 做测试服务器，server 配置为 Nginx + TLS1.3，多台客户端 vps 使用 wget 同时下载，协商的加密套件为 TLS_AES_256_GCM_SHA384。结果可以輕鬆跑滿 AWS 服务器 1Gbps 的出口帶寬，服务端 Nginx 进程 CPU 占用不超过 20%。加密方式根本不是速度的瓶頸。

所以，要麽請給出您的詳細評測方式和數據，要麽請停止这种无意义的宣傳推廣老舊加密套件的行爲，否則我有理由懷疑你的動機。

不要隨便謾罵，我用Vultr這類5美元/月的VPS，CPU是E3。用AnyConnect看YouTube 1080P，VPS的CPU使用率漲到50%。用SSH登入，SSH-AES-GCM-SHA2很卡，SSH-AES-CTR-SHA2很快。我說過表面上的Benchmark是GCM快過CBC。 你多試試幾個能用支付寶支付的廠商。 我用來看視頻已經試了很多次。不論Android/iOS，AnyConnect/Trojan用GCM耗電很快。所以為什麼有些人的手機寧願用海外4G也不用VPN。

[hyxxsfwy]

@rprx ARM/AMD/Intel試圖用SHA指令集解決SHA慢的問題。當年就是靠AES指令集才能從RC4、3DES成功過渡到AES。 另外低端VPS（便宜的單核/雙核VPS）和手機（當然Android/iOS）用AEAD加密都耗電和性能低下，看HD Video只能用TLS-AES-CBC-SHA2。包括WireGuard的ChaCha20-Poly1305-Blake2s也是，速度慢，在手機使用很耗電。

AES Golang Encryption Performance Benchmarks 据我所知，此類 BenchMark 的結論都是 AES-GCM 遠比 AES-CBC-HMAC 高效。從實際使用經驗看，AWS Lightsail 1C 1G 的低端 VPS 做测试服务器，server 配置为 Nginx + TLS1.3，多台客户端 vps 使用 wget 同时下载，协商的加密套件为 TLS_AES_256_GCM_SHA384。结果可以輕鬆跑滿 AWS 服务器 1Gbps 的出口帶寬，服务端 Nginx 进程 CPU 占用不超过 20%。加密方式根本不是速度的瓶頸。 所以，要麽請給出您的詳細評測方式和數據，要麽請停止这种无意义的宣傳推廣老舊加密套件的行爲，否則我有理由懷疑你的動機。

不要隨便謾罵，我用Vultr這類5美元/月的VPS，CPU是E3。用AnyConnect看YouTube 1080P，VPS的CPU使用率漲到50%。用SSH登入，SSH-AES-GCM-SHA2很卡，SSH-AES-CTR-SHA2很快。我說過表面上的Benchmark是GCM快過CBC。 你多試試幾個能用支付寶支付的廠商。 我用來看視頻已經試了很多次。不論Android/iOS，AnyConnect/Trojan用GCM耗電很快。所以為什麼有些人的手機寧願用海外4G也不用VPN。

沒有謾罵，只是指出您的描述中存在謬誤的事實。我們知道，非常的觀點需要更強的事實證據作為支持。拿出令人信服的證據，否則只自話自説你個人的“觀察”與“認為”是沒有意義的。 TLS1.3 是經過工業界嚴格的審計、測試、優化的，Google、CloudFlare 等流量大戶早已大規模部署。V2ray 有必要使用 Golang 庫提供的 TLS1.3 標準加密套件，以消除特徵，抵禦攻擊，保障信道安全，這是這段時間眾多開發者們達成的共識。任何試圖改變這一條原則的設計建議，都要接受嚴格的審視、評議。

[hyxxsfwy]

@rprx ARM/AMD/Intel試圖用SHA指令集解決SHA慢的問題。當年就是靠AES指令集才能從RC4、3DES成功過渡到AES。 另外低端VPS（便宜的單核/雙核VPS）和手機（當然Android/iOS）用AEAD加密都耗電和性能低下，看HD Video只能用TLS-AES-CBC-SHA2。包括WireGuard的ChaCha20-Poly1305-Blake2s也是，速度慢，在手機使用很耗電。

AES Golang Encryption Performance Benchmarks 据我所知，此類 BenchMark 的結論都是 AES-GCM 遠比 AES-CBC-HMAC 高效。從實際使用經驗看，AWS Lightsail 1C 1G 的低端 VPS 做测试服务器，server 配置为 Nginx + TLS1.3，多台客户端 vps 使用 wget 同时下载，协商的加密套件为 TLS_AES_256_GCM_SHA384。结果可以輕鬆跑滿 AWS 服务器 1Gbps 的出口帶寬，服务端 Nginx 进程 CPU 占用不超过 20%。加密方式根本不是速度的瓶頸。 所以，要麽請給出您的詳細評測方式和數據，要麽請停止这种无意义的宣傳推廣老舊加密套件的行爲，否則我有理由懷疑你的動機。

不要隨便謾罵，我用Vultr這類5美元/月的VPS，CPU是E3。用AnyConnect看YouTube 1080P，VPS的CPU使用率漲到50%。用SSH登入，SSH-AES-GCM-SHA2很卡，SSH-AES-CTR-SHA2很快。我說過表面上的Benchmark是GCM快過CBC。 你多試試幾個能用支付寶支付的廠商。 我用來看視頻已經試了很多次。不論Android/iOS，AnyConnect/Trojan用GCM耗電很快。所以為什麼有些人的手機寧願用海外4G也不用VPN。

關於 TLS 在低性能行動轉裝置和 IoT 設備上電量消耗的問題，業界也有大量的研究。比如這篇文獻：

Analyzing power consumption of TLS ciphers on an ESP32 (March 2019)

Despite the fact that these values have been obtained on a single IoT platform using a dedicated TLS implementation we obtained viable tendencies: • Using TLS on the ESP32 requires a significant amount of energy. Compared to an unencrypted transmission, approximately 14 times more energy is required to establish a full TLS session. • TLS 1.2 session resumption significantly reduces the required energy for IoT devices. At the moment of writing, TLS 1.3 session resumption has not been implemented. • Using ECDSA instead of RSA for TLS signatures is beneficial in terms of energy consumption. • TLS 1.3 further reduces the energy consumption for a full session compared to TLS 1.2.

個人的使用體驗是，TLS1.3 + WS + VMESS，沒有在手機和平板上觀察到明顯的電量損耗。

[okudayukiko]

更新，只要是TLS，不管AnyConnect還是Trojan，手機耗電問題幾乎無解。TLS的話建議分server和client模式，server模式可以指定TLS Cipher suite、ECDH Curve、Rekey timeout、Prefer Server Cipher，這些參數對TLS性能影響較大。Trojan用CHACHA20-POLY1305也耗電問題無解。

[RPRX]

@okudayukiko

刚刚手滑。。。

服务端最好不要 Prefer Cipher，否则客户端无法自动选择最适合自己的加密套件。

[wenjinlibug]

不知各位大佬是否願意聽一下外行人的意見，我不懂什麽加密套件加密原理，也不懂怎麽混淆才能騙過墻，僅僅作爲一個使用者來説，多一個協議選擇就代表墻要多分一份資源來防堵，如果只需要投入極少的人力簡單的合并到v2ray裏何樂而不爲？誰規定VLess合并后就一定要分出大量人力來維護了？至於Vmess的混淆加密等確實不是性能瓶頸，畢竟手機、電腦、服務器、綫路帶寬都會更新換代硬件性能提升遲早會完全蓋過那點性能損失，可問題的根本不在那裏，真正的問題在於“最沒特徵的人是間諜”，沒特徵本身就是最大特徵，現在的Vmess看起來就像毫無意義的强調無特徵和強加密。

[Sanfrencon]

我觉得应该从普通使用者的角度来考虑这个问题，如果是用来爬墙的话加解密速率不是大问题，服务与线路的稳定才是核心。目前看评论，开发VLess在我看来很大程度上有与Trojan比较的想法。讨论的计算资源占用问题，个人认为新的加密算法或者协议集成下就可以。vmess协议或者ss协议或者其它，来个开关，想用就用，不用你就明文再套个其它加密也行。这样组合更多，有的选，大家选自己最喜欢的就好，不用吵架。

V2ray在我心中应该更像一把瑞士军刀，提供更多选择与组合的同时，不断添加新的工具可以用，而不是简单为了翻墙去设计。我也经常用v2ray做国内的代理和转发，感觉配置简单很好用。个人期望v2ray在网络可靠性上有更好的设计，无论是改良目前UDP缺点，还是提供一个较好的负载均衡功能。都可以用比较小的成本，换取更稳定的网络体验。

[RPRX]

感觉楼上几位朋友误解了。。。现在并没有什么冲突。。。

[okudayukiko]

或者支持VMess+SSH。SSH支持的算法（Host key、Keyex、Encrypt、MAC）更多，在客戶端紀錄Base64 Public key或Public key fingerprint防止攻擊。 OpenVPN（TLS tunnel mode除外）、Tinc可以調用OpenSSL Library支持的算法，不受TLS Ciphersuite限制。

[RPRX]

@okudayukiko

SSH 自带 Socks5 代理（几年前流行的翻墙方式）

[RPRX]

@okudayukiko

刚刚 GitHub 崩了很长时间，没仔细看，回复也是过了好久才终于发出去

SSH 的 Socks5 是否有明显区别于 SSH 的特征还有待研究（我还没研究过

[okudayukiko]

這幾天在VPS上添加了2GB的swap file，再把原來.XYZ的域名換為.COM，解決了用Trojan看視頻時VPS端CPU使用率高的問題。 Trojan伺服器端或用戶端只協商一個TLS Cipher，看視頻緩慢的問題解決。 { "run_type": "server",（或"run_type": "client",） "ssl": { "cipher": "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256", "cipher_tls13": "TLS_AES_128_GCM_SHA256" } } SSH用戶端使用以下命令（手動指定一個Cipher）也可以用SSH SOCKS5代理：ssh -D 1080 -o Ciphers=aes128-gcm@openssh.com user@host、ssh -D 1080 -o Ciphers=chacha20-poly1305@openssh.com user@host、ssh -D 1080 -o Ciphers=aes128-ctr -o MACs=hmac-sha2-256-etm@openssh.com user@host。直接用ssh -D 1080 user@host會被中國防火牆阻斷（預設情況下SSH客戶端會協商多個Ciphers），應該是被降級攻擊（對umac-xxx-etm@openssh.com和umac-xxx@openssh.com進行阻斷）。 Ocserv則使用以下配置，只協商一個TLS Cipher。 /etc/ocserv/ocserv.conf tls-priorities = "NONE:+VERS-ALL:+ECDHE-RSA:+ECDHE-ECDSA:+SIGN-ALL:+AES-128-GCM:+AEAD:+GROUP-SECP256R1:+CURVE-SECP256R1"

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days