v2fly/v2fly-github-io

V2Fly Website & Documentation

V2Fly Website & Documentation

Translation contribution is on Transifex.

v2fly-github-io's Issues

"Quick start" button on the landing page ignores localization settings

It points to Chinese version as well, even if there is an English version.

关于 TLSObject 中 serverName 配置项的描述过于含糊

指定服务器端证书的域名，在连接由 IP 建立时有用。当目标连接由域名指定时，比如在 Socks 入站时接收到了域名，或者由 Sniffing 功能探测出了域名，这个域名会自动用于 serverName，无须手动配置。

该段描述存在以下疑点：

• “连接”和“目标连接”是指客户端与被代理的网站还是指与代理服务器的连接？

• 相应地，域名是指服务器的域名还是被代理网站的域名？

SOCKS 5 的认证在使用 UDP 时可被绕过

Author: @studentmain
Send Date: 2021-01-08

v2ray 等代理软件的内置 SOCKS 服务器对所有客户端共用同一 UDP 端口，导致其 SOCKS 5 UDP 服务无需认证即可使用。

复现

为代理软件的 SOCKS 入站配置密码，对于 v2ray 可参考以下配置文件：

{
   "log":{
      "loglevel":"warning"
   },
   "inbounds":[
      {
         "port":1080,
         "listen":"127.0.0.1",
         "tag":"socks-inbound",
         "protocol":"socks",
         "settings":{
            "auth":"password",
            "udp":true,
            "accounts":[
               {
                  "user":"a",
                  "pass":"a"
               }
            ],
            "ip":"127.0.0.1"
         }
      }
   ],
   "outbounds":[
      {
         "protocol":"freedom",
         "tag":"direct"
      },
      {
         "protocol":"blackhole",
         "tag":"blocked"
      }
   ]
}

验证密码是否已起效：

$ curl -x socks5://127.0.0.1:1080/ http://baidu.com/
curl: (7) No authentication method was acceptable. (It is quite likely that the SOCKS5 server wanted a username/password, since none was supplied to the server on this connection.)
$ curl -x socks5://a:[email protected]:1080/ http://baidu.com/
curl: (7) User was rejected by the SOCKS5 server (1 255).
$ curl -x socks5://a:[email protected]:1080/ http://baidu.com/
(HTML content)

向 v2ray 设定的 UDP 端口直接发送一个 SOCKS 5 UDP 包（以 DNS 查询为例），用 Wireshark 等监视，若服务端有任何响应，则漏洞存在

$ base64 -d | nc -u 127.0.0.1 1080 | hd
AAAAAXJycnIANavNAQAAAQAAAAAAAAN3d3cHZXhhbXBsZQNjb20AAAEAAQ==
00000000  00 00 00 01 72 72 72 72  00 35 ab cd 81 80 00 01  |....rrrr.5......|
00000010  00 01 00 00 00 00 03 77  77 77 07 65 78 61 6d 70  |.......www.examp|
00000020  6c 65 03 63 6f 6d 00 00  01 00 01 c0 0c 00 01 00  |le.com..........|
^C

分析

SOCKS 5 要求 UDP 客户端先通过 SOCKS 5 TCP 协议请求服务端分配用于通信的 UDP 端口。SOCKS 5 TCP 协议允许多种认证方式，而 SOCKS 5 UDP 协议自身没有任何区分客户端的机制，需通过报文源端口来区分不同的客户端。

当 SOCKS 5 服务端对所有客户端分配同一 UDP 端口时，因为无法预测客户端使用的 UDP 源端口，服务端必须始终接受来自任意源地址的 UDP 报文。在此种情况下，服务端没有措施保证 UDP 客户端已经认证。

解决方案

对每一个 SOCKS 5 UDP ASSOCIATE 请求分配独立的 UDP 端口，此 UDP 端口在收到第一个数据报后忽略来自其他源地址的数据报。

虽 SOCKS 5 UDP 协议自身仍然没有认证，但不固定端口使得攻击者需要进行扫描才能找到 SOCKS 5 UDP 端口。而已经开始监听的 UDP 端口有很大可能在监听开始后极短时间（1RTT）即已收到来自客户端的首个数据报，进而忽略来自端口扫描器的数据报。

未实现任何认证的服务端因为本就没有认证，可忽略该漏洞，仍然对所有客户端分配同一 UDP 端口。显然地，已经实现认证的
SOCKS 服务端也可通过移除认证机能来忽略该漏洞。

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEdbyjO018JNZhjd2SqnhRnCCMh0IFAl/2+vAACgkQqnhRnCCM
h0J07A/9H3BOim+1Q8Ob5KrBUM7C2+769Go7AaTVNnrB6ACooXcuXCytyorN4Bz9
W8w9xqNAjZ67P4yYl3MMZl7zWnoLrT9oG2vebFB4HHd3Os6CKkkyWARoyVZUlAbZ
XsreOvf5JIEg+XUBsPFSZkmmuGPK9r/txTpgJyYDIZAqk5weP9+FfnKceu2cXHau
cwp2IAWtbo/3JxOsoYmEF1ZuarMy61HsNITfAqjNjeuluGUAWfwyCVv8Kph5czy9
ZHdcuZc+R4jawbGLO0T9uUckqcDqhBu+k+LwepLeObmzb7lMy5avvGO2oSNRqfvY
SmI+/9RzoCwfHoBWJLb02k9UKhKO4QUClYGHyr04Ht1KX5dBAm14S2JlKBGbjFIi
kGNE8xkxUnJ8Wzpg0w4WqaI8WY85lZ2T0OfVsfpqTHgkxQ/JhTiiFQ3flAsAwAYy
M7Pg3ptNY0PrPYw6n7/zQfwQ/iPvL41cuG1RvLR0cLJYw4R4qF3DEmoF3eMHwCJB
QzAzNTkL9rX2RzNdTpUh/TTyt02wRvmlPuRaI4vLBJEB3ohoO8YEIiqsc6XRRui2
/rEbI4ZKepsPGGFfFmUMieuqE34ojzwE429xVBYgi9Ct7EcR2xqOkTG/eCufPq2a
kS4VqszMtBWuWJdymthzE933Kok1wvraoWUgIcfWKA+KzT/mekQ=
=2gl8
-----END PGP SIGNATURE-----

新手求救：关于如何屏蔽奇怪的 incoming IP traffic

在配置好V2RAY之后，运行一切正常，但是在LOG中会高频出现以下内容：

2021/09/07 15:57:07 tcp:123.56.44.26:58722 accepted tcp:zhihu.com:80 [direct]
2021/09/07 15:57:16 tcp:101.200.155.159:46248 accepted tcp:103.41.167.234:80 [direct]
2021/09/07 15:57:19 tcp:123.56.44.26:44690 rejected proxy/socks: insufficient header > EOF

想用iptables将以上IP地址BLOCK在WAN之外，路由器系统：openwrt
曾经尝试：
iptables -A INPUT -s 123.56.44.26 -j DROP
或
iptables -t nat -A V2RAY -s 123.56.44.26 -p tcp -j RETURN
或类似命令，都无法屏蔽掉以上IP，实在不知如何解决，所以在此询问，感谢。

[已解决]
iptables -t filter input_rule -s xxx.xxx.xxx.xxx -j DROP

各位打扰了

Consider migrating to vitepress.

Vitepress is the "next generation" of vuepress. And it finally released v1.0 recently. It's time to migrate。

Why we need to migrate

访问 v2fly.org 时浏览器会向第三方域名发起请求

事情的起因是，最近我在统计自己访问的网站，想要维护一个自己经常访问的外国网站列表。今晚在整理日志的过程中发现了一个很不常见的域名

api.xuann.wang

经调查发现是官方文档 v2fly.org 网站上用于显示贡献者名单的 VuePress 插件所致，由该插件作者（大概也是域名控制人）的 PR #58 引入。

个人认为处于安全考虑，v2fly.org 不应请求由他人控制的域名。毕竟访问该网站的极大概率只有两种人：v2ray 的开发者、v2ray 的用户。而对第三方域名发起请求至少会暴露访问者所使用的 IP 地址和浏览器 UA 等信息。

在这里不是想指控任何人，实际上该域名所指向的服务器会不会记录上述的隐私信息也无所谓：有能力记录本身就是问题所在

[VLESS][fallbacks]数组元素的排列顺序对配置有没有影响

fallbakcs数组元素的排列顺序对配置有没有影响，文档中没有说清楚

[Question]Does v2 relay udp connections, or sstap alike are needed for that?

On windows and android.
Can v2 redirect udp connections on it's own or not?
Some games and what not are using udp as their connection protocol.

Can't navigate to routing page.

v4 英文版 配置文档的 routing 部分不可访问。但中文版本可以。
文档地址 https://www.v2fly.org/en_US/config/routing.html

[en_US] Inbound config 404

/en_US/config/inbounds.html is 404 as for now.
Maybe it would be better to place a stub about not yet translated pages?

建议在 README 或官网中写一下现在使用的翻译管理平台的信息

据我了解，现在项目使用的了翻译管理平台 transifex。这个平台可以提供中英文对照之类的功能。
那么是不是可以将这部分介绍写进 README 或官网文档里，介绍给想要贡献翻译的所有用户呢？

VMess协议的FNV端序没有描述清楚

https://www.v2fly.org/developer/protocols/vmess.html

校验 F：指令部分除 F 外所有内容的 FNV1a hash；

按照定义，FNV算法给出的是一个整数，而非字节序列。为严谨起见，应注明使用了Big-Endian。

v5 config 文档是在干嘛？

找个 socks auth 设置半天找不到，有什么参考意义吗？

那个什么秋枫到底写得什么玩意。

error 404 page Then run V2Ray in command line.

https://www.v2fly.org/en_US%2Fguide%2Fcommand.html

sniffing 文档不详细

sniffing 的文档过于简略，有很多问题没有说。比如 sniffing 具体操作是什么，作用在哪些协议上，从这些协议中能 sniff 出什么信息，对于不同 inbound 类型有什么不同行为，metadataOnly 开与不开的行为有什么区别（具体什么信息算 metadata），sniff 出的信息在程序的其他部分（如路由）能被怎样使用等等.. 希望了解细节的开发者能将其补全，谢谢。

最新版本没有可选[全局]和[绕过大陆]的设置了吗？

最新版本右键菜单没有可选[全局]和[绕过大陆]的设置了吗？
只有【系统代理】和【服务器】两个设置项了

更新vmess协议

https://www.v2fly.org/developer/protocols/vmess.html

I have the next problem Main: config file not readable > open /root/config.json

when starting the v2ray command with root from it I get this I have ubuntu 18.4

V2Ray v2.37 (One for all) 20170907 An unified platform for anti-censorship. Main: config file not readable > open /root/config.json: no such file or directory

Help meeee !!! Pleaseeee

Fail to generate href tags

The href tags in here are generated failed: https://www.v2fly.org/chapter_02/env.html

And also failed in the same page: https://www.v2fly.org/chapter_02/03_routing.html

Encryption method options inconsistent with implementation of v2ray-core

Options listed in vmess protocols page are

Encryption method: Specify the encryption method of the data part, the optional values are:
0x00: AES-128-CFB;
0x01: No encryption;
0x02: AES-128-GCM;
0x03: ChaCha20-Poly1305;

but values in common/protocol/headers.pb.go referenced in proxy/vmess/encoding/server.go are

// Enum value maps for SecurityType.
var (
	SecurityType_name = map[int32]string{
		0: "UNKNOWN",
		1: "LEGACY",
		2: "AUTO",
		3: "AES128_GCM",
		4: "CHACHA20_POLY1305",
		5: "NONE",
		6: "ZERO",
	}
	SecurityType_value = map[string]int32{
		"UNKNOWN":           0,
		"LEGACY":            1,
		"AUTO":              2,
		"AES128_GCM":        3,
		"CHACHA20_POLY1305": 4,
		"NONE":              5,
		"ZERO":              6,
	}
)

VMessAEAD 设计文档

1. 现状

目前 VMess 已可根据协议头自动协商使用 AEAD 加密并认证传输的流量。但 VMess 协议头部仍然使用 MD5 + AES-CFB ，不能保证协议头部自身的完整性。

2. 定义

KDF: KDF 接受一个字节数组形式的主密钥，和若干字节数组形式的路径，生成一个子密钥

func KDF(key []byte, path [][]byte) []byte {
    oKDF = HMAC(SHA256, "VMess AEAD KDF")
    for in_v := range path {
        oKDF = HMAC(oKDF, in_v)
    }
    return oKDF(key)
}

CmdKey: 由用户 UUID 产生的一个字节数组形式密钥

const IDBytesLen = 16

type ID struct {
    uuid   uuid.UUID
    cmdKey [IDBytesLen]byte
}

func (id ID) CmdKey() []byte {
    return id.cmdKey[:]
}

3. EAuID

为了保持和原有协议，配置兼容，继而保证全部用户都可以享受到这个更新，必须要通过且仅通过最开始16个字节计算出客户端的UUID信息。

3.1 EAuID

EAuID 明文为 [Timestamp 8B][Rand 4B][CRC 4B]

Timestamp 为以秒为单位的64位 Unix 时间戳
Rand 为随机数
CRC 为 CRC32([Timestamp, Rand]) IEEE 多项式

EAuID 密钥为 KDF(CmdKey, ["AES Auth ID Encryption"])
EAuID 使用 AES-128 块加密

3.2 ELength

ELength 是经过 AES-128-GCM 加密的 16 位大端序 VMess 包头部长度。
加密密钥为 KDF(CmdKey, ["VMess Header AEAD Key_Length", EAuID, Nonce])
不重数为 KDF(CmdKey, ["VMess Header AEAD Nonce_Length", EAuID, Nonce])
附加数据为 EAuID

3.3 EHeader

经过 AES-128-GCM 加密的 VMess 标准首部
加密密钥为 KDF(CmdKey, ["VMess Header AEAD Key", EAuID, Nonce])
不重数为 KDF(CmdKey, ["VMess Header AEAD Nonce", EAuID, Nonce])
附加数据为 EAuID

3.4 整体格式

[EAuID][ELength][Rand 8B][EHeader]

Rand 是 64 位随机数

3.5 验证流程

对于每个客户端发来的 EAuID

1. 进行重放检测，如果之前 120 秒内见过这个 EAuID 就终止检测，结果为重放错误。
2. 针对每一个服务器上用户的 UUID。
3. 根据 UUID 生成 CmdKey（用戶 UUID），并解密 EAuID。
4. 校验 AuID.zero 如果 CRC32 结果错误终止第二步 2 的本轮循环，继续尝试下一个 UUID。
5. 校验 AuID.Time 如果时间差超过允许的数值结果错误终止第二步 2 的本轮循环，继续尝试下一个 UUID。
6. 如果进行至这步校验完成，终止检测 结果为 初步认证成功 本轮的 UUID 为认证用户的 UUID。

4. VMessAEAD 包头

4.1 ALength

AES-128-GCM 加密的 16 位大端序包头部长度。
加密密钥为 KDF(CmdKey, ["VMess Header AEAD Key_Length", EAuID, Nonce])[:16]
不重数为 KDF(CmdKey, ["Vmess Header AEAD Nonce_Length", EAuID, Nonce])[:12] 附加数据为 EAuID

目的在与尽早完成对客户端的验证(注1)

• 必须发送长度否则不知道要读取多少信息
• 必须验证 EAuID，防止攻击者抓取阻止新请求后用新 EAuID 和旧的 Nonce，MaskedLength 一起构造重放攻击
• 必须验证 Length，防止攻击者修改长度，后面的 MaskedLength 没有独立的认证
• 必须验证 Nonce，如果 Nonce 错误解密会失败，要尽早验证 (注1)
• 必须加盐，此用户 UUID (CmdKey) 还有其他用途

4.2 Aheader

经过 AES-128-GCM 加密的 VMess AEAD 首部
加密密钥为 KDF(CmdKey, ["VMess Header AEAD Key", EAuID, Nonce])[:16]
不重数为 KDF(CmdKey, ["VMess Header AEAD Nonce", EAuID, Nonce])[:12] 附加数据为 EAuID

数据是VMess的整个未加密头部，从版本号到校验数据。目的是简化支持AEAD的难度，减少非必要的协议修改。

AES-GCM 要求 Key-Nonce 组合不重复。由于其中使用了 EAuID, Nonce 作为Key，Nonce 的 KDF 输入，有96位随机熵输入不会重复。因为使用用户 UUID 作为输入无法被攻击者解密。 这两个 AEAD 输入都必须加盐因为用户 UUID 还有其他用途。

4.3 整体格式

[EAuID][ALength][Rand 8B][Aheader]

Rand 是 64 位随机数

4.4 VMessAEAD 处理流程

1. 读取 EAuID / 或原协议认证信息 16 字节。
2. 根据 EAuID / 或原协议认证信息判断是否应该使用 AEAD 方法读取协议头。如果是旧协议的话就用原来的方法并返回结果。
3. 继续读取 AuIDCheck，MaskedLength，Nonce。此时已经读取了 42 字节 <= 38 + 16 Drain 的初始值。
4. 解除 MaskedLength 的混淆为 Length。
5. 验证 AuIDCheck 数值，如果不正确则进行 Drain。
6. 读取 AEADVMessHeader，解密为 VMessHeader 并进行相应处理并返回结果。

VMessAEAD 协议的返回头也会使用 AEAD 方式进行加密，方法类似请求包头。但是密钥数据来自连接密钥 + KDF。发送 AEAD 加密的 MaskedLength，之后是内容。

客户端必须记忆自己是否使用了 VMessAEAD 发送包头，在使用 VMessAEAD 替换掉了一些 MD5 等弱密码学函数，即使这些弱密码学函数尚不构成任何已知协议弱点。

注1：
阻止抓包 + 重放攻击者根据读取长度来确定服务器类型，如果需要读取过多数据，那么就会超出计算出的 Drain 值长度，无法通过 Drain 隐藏服务器处理流程。
为了保证 Drain 能正常运行，必须在读取 38 + 16 个字节前决定此连接是否来自真实客户端。

• AuIDCheck 保证在读取 42 字节时已经得到 211 位校验熵，确定不是来自抓包 + 部分重放。

d

VMess 分享链接标准 Draft 1

1. 为什么提议指定官方标准？

现有的主流 vmess:// 分享链接分为以下几种：

1. V2RayN 格式
2. ShadowRocket 格式
3. Quantumult 格式
4. 等……

以上分享链接协议仅仅适用于自家软件的导入/导出，普通用户如需要转换则需要第三方组件，在无形之中增加了链接配置被恶意盗用的可能性。

另外，V2Ray 现已然成为一个平台化程序，我认为有必要设计一个 VMess 协议的标准分享链接格式，这对于个人用户在设备间分享 / 机场进行标准化适配 / 新客户端编写都具有更多的便利性

2. 标准格式提议

新的 vmess:// 标准应当避免使用 Json 存储，同时应当避免大量使用 Base64：

• Json 是数据交换格式，但不应用在 URL 中，URL 标准有 Query 项目可以存储协议相关设置

• Base64 的输出会导致配置项不便于观察，在此基础上，Base64 并不能防止数据篡改或因为传输原因损坏：

  echo "SGVsbG8K" | base64 -d
  #---> Hello
  echo "SGRsbG8K" | base64 -d
  #---> Hdllo

3. 链接格式标准

下列标准使用类 Python 语法的伪代码编写

在标准中，bool 类型的值将遵循以下规定：

• 表示 假 的值：false, False, No, Off, 0, "" （空字符串，如 useSomething=）
  • 大小写不敏感
• 其余值如果出现，将解析为真

PROTOCOL_OPTION_OBJECT = struct { 名称, 值类型, 默认值 }

# PROTOCOL_OPTIONS = [ PROTOCOL_OPTION_OBJECT ]

PROTOCOL_OPTIONS = []
# QUIC 和 KCP 所需的混淆类型
QUIC_KCP_HEADERS_TYPES = enum { "none", "srtp", "utp", "wechat-video", "dtls", "wireguard" }
# QUIC 所需的 Security 类型
QUIC_SECURITY_TYPES = enum { "none", "aes-128-gcm", "chacha20-poly1305" }
# TCP 所需的 Type
TCP_TYPES = enum { "none", "http" }

switch streamSettings.protocol:
    case TCP:
        PROTOCOL = "tcp"
        PROTOCOL_OPTIONS += { "type", TCP_TYPES, "none" }
        PROTOCOL_OPTIONS += { "host", string, "" }

    case HTTP:
        PROTOCOL = "http"
        PROTOCOL_OPTIONS += { "path", string, "/" }
        # 每个 Host 项使用 "|" 分割
        PROTOCOL_OPTIONS += { "host", string, "" }

    case WS:
        PROTOCOL = "ws"
        PROTOCOL_OPTIONS += { "path", string, "/" }
        PROTOCOL_OPTIONS += { "host", string, "" }

    case KCP:
        PROTOCOL = "kcp"
        PROTOCOL_OPTIONS += { "type", QUIC_KCP_HEADERS_TYPES, "none" }
        PROTOCOL_OPTIONS += { "seed", string, "" }

    case QUIC:
        PROTOCOL = "quic"
        PROTOCOL_OPTIONS += { "security", QUIC_SECURITY_TYPES, "none" }
        PROTOCOL_OPTIONS += { "key", string, "" }
        PROTOCOL_OPTIONS += { "type", QUIC_KCP_HEADERS_TYPES, "none" }

TLS_OPTIONS = []
if hasTLS:
    # TLS 配置
    # e.g.
    #     ws+tls
    #     ws
    #     quic+tls
    #     tcp
    URL_USERNAME_PART = PROTOCOL + "+tls"

    # AllowInsecure 选项扬了
    TLS_OPTIONS += { "tlsServerName", string, "" }
else:
    URL_USERNAME_PART = PROTOCOL


# UUID: 带 "-" 分割的 UUID
# alterId: int
# host: string
# port: int
# e.g. "kcp+tls:[email protected]:1234"
URL_PART_A = f"{URL_USERNAME_PART}:{UUID}-{alterId}@{HOST}:{PORT}"

# 协议相关设置项，值使用 encodeURIComponent 编码
URL_PART_B = [for OPT in PROTOCOL_OPTIONS, f"{OPT.名称}={encodeURIComponent(OPT.值)}"].join("&")

# TLS 相关设置项，值使用 encodeURIComponent 编码
URL_PART_C = [for OPT in TLS_OPTIONS, f"{OPT.名称}={encodeURIComponent(OPT.值)}"].join("&")

# ALIAS: string
URL_PART_D = encodeURIComponent(ALIAS)

FULL_VMESS_URL = "vmess://" + URL_PART_A + "/?" + URL_PART_B + URL_PART_C + "#" + URL_PART_D

链接格式解析样例

vmess://ws+tls:[email protected]:12345/?path=%2FmyServerAddressPath%2F%E4%B8%AD%E6%96%87%E8%B7%AF%E5%BE%84%2F&host=www.myServer.com&tlsAllowInsecure=true&tlsServerName=%E4%BC%AA%E8%A3%85%E5%9F%9F%E5%90%8D.com#%E4%B8%AA%E6%80%A7%E5%8C%96%E9%93%BE%E6%8E%A5%E5%A4%87%E6%B3%A8

传输协议: WS + TLS
UUID/AlterID: 7db04e8f-7cfc-46e0-9e18-d329c22ec353 / 64
服务器地址/端口: myServer.com:12345
协议设置: path=/myServerAddressPath/中文路径/
		 host=www.myServer.com
TLS 设置：SNI: 伪装域名.com
连接名："个性化链接备注"

vmess://kcp:[email protected]:443/?type=srtp#AirportConnection1

传输协议: KCP
UUID/AlterID: ba1b8f8f-efe6-427f-99b2-50491f0adf86/10
服务器地址/端口: baidu.com:443
协议设置： type=srtp
连接名： AirportConnection1

vmess://unknown:[email protected]:4433/?query=Value1#Connection2
"unknown" 不是 V2Ray 已知传输协议，因此 vmess 链接非法

vmess://tcp:[email protected]:4433/?query=Value1#Connection2

传输协议: TCP
UUID/AlterID: 2e09f64c-c967-4ce3-9498-fdcd8e39e04e/10
服务器地址/端口: google.com:4433
协议设置: TCP type 由于未在链接中出现，所以使用默认值 none
         链接中 "query" 项忽略
连接名: Connection2

Update: V2Ray-core 新增了 KCP Seed，因此更新
Update: 更新 TLSServerName 为 tlsServerName
Update: 新增 TCP 在 HTTP 伪装时的 host 字段

Update: 移除了 tlsAllowInsecure 项

LICENSE PROBLEM

In LICENSE: Attribution 4.0 International (CC BY 4.0)
In Website: 网站（v2fly.org ）以 CC BY SA 4.0 国际许可协议 授权

WHICH ONE?

[XTLS]

db182c7

UDP/443 的请求改为443端口的UDP请求会好一些
@RPRX

[Transport][TLSObject]

disableSystemRoot: true | false

（V2Ray 4.18+）是否禁用操作系统自带的 CA 证书。默认值为 false。当值为 true 时，V2Ray 只会使用 certificates 中指定的证书进行 TLS 握手。当值为 false 时，V2Ray 只会使用操作系统自带的 CA 证书进行 TLS 握手。

其中：

当值为 false 时，V2Ray 只会使用操作系统自带的 CA 证书进行 TLS 握手。

这个地方是不是写错了，应该是：

当值为 false 时，允许使用操作系统自带的 CA 证书进行 TLS 握手。

还有默认值是不是应该改为true比较好，Nginx等Web服务，难道会用操作系统中的CA证书和客户端握手？

Add DocSearch Support

Website: https://docsearch.algolia.com/
VuePress docs: https://vuepress.vuejs.org/theme/default-theme-config.html#algolia-search

The path in the compilation documentation may be wrong

https://github.com/v2fly/v2fly-github-io/blob/master/docs/en_US/developer/intro/compile.md?plain=1#L32

It's seem that there is no "/infra/control/main" directory in the v2ray-core repo.

v4配置文档"domain"项问题

{ "routing": { "rules":[ {"domain": []} <---- 这个配置项 ] } }
v2fly.org上的v4配置文档使用"domains"，但v4 Releases内置默认的config.json却使用"domain"，究竟哪一个才正确还是两个都正确？

Route rules not work proper on - domain

I set the Route rule for YouTube bypass for proxy
Domain:youtube.com
outbound: Bypass

but YouTube.com use a proxy connection instead of a direct connection.

Also, a domain that has link more IP can bypass? example - a92-123-102-129.deploy.static.akamaitechnologies.com (CDN domain)

I show that All CDN domains did not work on rules.

[Warning] failed to handler mux client connection > v2ray.com/core/proxy/vmess/outbound: connection ends > v2ray.com/core/proxy/vmess/outbound: failed to read header > v2ray.com/core/proxy/vmess/encoding: failed to read response header > EOF 2021/03/07 16:03:59 tcp:127.0.0.1:4093 accepted tcp:content-autofill.googleapis.com:443 [proxy]

2021/03/07 16:03:48 tcp:127.0.0.1:4075 accepted tcp:www.google.com:443 [proxy]
2021/03/07 16:03:48 tcp:127.0.0.1:4076 accepted tcp:content-autofill.googleapis.com:443 [proxy]
2021/03/07 16:03:48 tcp:127.0.0.1:4077 accepted tcp:www.google.com:443 [proxy]
2021/03/07 16:03:48 tcp:127.0.0.1:4078 accepted tcp:www.google.com:443 [proxy]
2021/03/07 16:03:48 tcp:127.0.0.1:4079 accepted tcp:www.google.com:443 [proxy]
2021/03/07 16:03:51 tcp:127.0.0.1:4084 accepted tcp:www.gstatic.com:80 [proxy]
2021/03/07 16:03:59 [Warning] failed to handler mux client connection > v2ray.com/core/proxy/vmess/outbound: connection ends > v2ray.com/core/proxy/vmess/outbound: failed to read header > v2ray.com/core/proxy/vmess/encoding: failed to read response header > EOF

please help me,thanks

关于V5版本配置文件的一些问题

是否未完全更新或者缺漏？包括：

• inbound模块下是否缺失了表示对应“用户”的标识，用于router模块的“userEmail”字段使用。（想vmess等支持多用户的，现在只区分了一个uuid；socks、shadowsocks的用户标识也没有了）
• dns模块中的fakedns部分，是否延续v4时的配置模式，将“fakedns”放来服务器列表第一项就能处理先fakedns的数据，还只需要在dns模块下的fakedns字段添加配置项就可以优先生效处理？

希望可以出一篇基于 DOH 方式的 透明代理教程，谢谢

希望可以出一篇基于 DOH 方式的 透明代理教程，谢谢

sniffing 文档不详细

sniffing 的文档过于简略，有很多问题没有说。比如 sniffing 具体操作是什么，作用在哪些协议上，从这些协议中能 sniff 出什么信息，对于不同 inbound 类型有什么不同行为，metadataOnly 开与不开的行为有什么区别（具体什么信息算 metadata），sniff 出的信息在程序的其他部分（如路由）能被怎样使用等等.. 希望了解细节的开发者能将其补全，谢谢。

Reverse页面超链接错误

https://www.v2fly.org/config/reverse.html
里面的BridgeObject和PortalObject超链接应该带上#号，指向本页面的相应位置

Does "awesome tools" accept "not free" app?

I have made an app which focusses on V5 core, and only supports Apple platform, like macOS and iOS.
The price is free. The free functions contain most necessary features, like router and subscription. But it also offer some vip features, like cleaning configs and predefining templates.
I think it will be useful for v2ray users.
The macOS version has passed Apple Review and be available on Mac App Store. Here is the link of Wings V Client.

I'm not sure that wether your team accpets "not free" application, because I won't open source of the app.

If it can be accepted, I'll open a PR to submit it.
If not, please just close this issue.

Sorry for boring you.

关于 sniffing 文档的描述过于含糊

Inbounds

Inbounds 文档中关于 sniffing 的说明太笼统，并且“流量探测”的描述也不够准确。建议：

• 说明 sniffing 作用在V2ray内部产生的数据内容类型（如流量类型、协议类型、域名等）；
• 说明 sniffing 的应用场景。（如 socks 代理下根据分流等）。

The path in the documentation is wrong.

https://github.com/v2fly/v2fly-github-io/blob/master/docs/en_US/developer/intro/compile.md?plain=1#L32

The Git repository does not have this path: /infra/control/main

是否应该注明工具的开源、闭源状态？

有一些 GUI 客户端以前是开源的，但是后来闭源了。
我不评价这个行为，只是认为需要一定程度上保障用户的知情权，避免发生误会。
对一些人来说，这也事关“安全”。

Re

https://discord.com/invite/bnEcadYB

[Dokodemo-door]配置文件说明错误

根据：https://www.v2fly.org/config/inbounds.html#inboundobject

settings: InboundConfigurationObject

具体的配置内容，视协议不同而不同。详见每个协议中的 InboundConfigurationObject。

和：https://www.v2fly.org/config/protocols/dokodemo.html#inboundconfigurationobject

InboundConfigurationObject
{
    "address": "8.8.8.8",
    "port": 53,
    "network": "tcp",
    "timeout": 0,
    "followRedirect": false,
    "userLevel": 0
}

Dokodemo-door的address、port、network、timeout、followRedirect、userLevel应该全部在settings中。

而：https://guide.v2fly.org/app/tproxy.html#%E9%85%8D%E7%BD%AE%E9%80%8F%E6%98%8E%E4%BB%A3%E7%90%86
中，却与之违背。
实测新白话文指南的配置是可行的

feat：可否增加一个配置透明代理的说明

可否有大神出点教程怎么配置透明代理？
iptables 或其他等等方式的？

Thanks very much for contributing! Your pull request has been merged 🎉 You should see your changes appear on the site in approximately 24 hours. If you're looking for your next contribution, check out our [help wanted issues](https://github.com/github/docs/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) :zap:

Thanks very much for contributing! Your pull request has been merged 🎉 You should see your changes appear on the site in approximately 24 hours. If you're looking for your next contribution, check out our help wanted issues ⚡

Originally posted by @github-actions in github/docs#29848 (comment)