diff --git a/docs/development/protocols/vless.md b/docs/development/protocols/vless.md index 6530654..e4ff1b0 100644 --- a/docs/development/protocols/vless.md +++ b/docs/development/protocols/vless.md @@ -4,13 +4,13 @@ VLESS 是一个无状态的轻量传输协议,可以作为 Xray 客户端和 ## Request & Response -|1 字节|16 字节|1 字节|M 字节|1 字节|2 字节|1 字节|S 字节|X 字节| -|-|-|-|-|-|-|-|-|-| -|协议版本|等价 UUID|附加信息长度 M|附加信息 ProtoBuf|指令|端口|地址类型|地址|请求数据| +| 1 字节 | 16 字节 | 1 字节 | M 字节 | 1 字节 | 2 字节 | 1 字节 | S 字节 | X 字节 | +| -------- | --------- | -------------- | ----------------- | ------ | ------ | -------- | ------ | -------- | +| 协议版本 | 等价 UUID | 附加信息长度 M | 附加信息 ProtoBuf | 指令 | 端口 | 地址类型 | 地址 | 请求数据 | -|1 字节|1 字节|N 字节|Y 字节| -|-|-|-|-| -|协议版本,与请求的一致|附加信息长度 N|附加信息 ProtoBuf|响应数据| +| 1 字节 | 1 字节 | N 字节 | Y 字节 | +| ---------------------- | -------------- | ----------------- | -------- | +| 协议版本,与请求的一致 | 附加信息长度 N | 附加信息 ProtoBuf | 响应数据 | VLESS 早在第二个测试版 ALPHA 2 时就已经是上述结构了(BETA 是第五个测试版): @@ -35,7 +35,7 @@ https://github.com/XTLS/Xray-core/issues/158 似乎只有 VLESS 可选内嵌 ProtoBuf,它是一种数据交换格式,信息被紧密编码成二进制,TLV 结构(Tag Length Value)。 起因是我看到一篇文章称 SS 有一些缺点,如没有设计错误回报机制,客户端没办法根据不同的错误采取进一步的动作。 - (但我并不认同所有错误都要回报,不然防不了主动探测。下一个测试版中,服务器可以返回一串自定义信息。) +(但我并不认同所有错误都要回报,不然防不了主动探测。下一个测试版中,服务器可以返回一串自定义信息。) 于是想到一个可扩展的结构是很重要的,未来它也可以承载如动态端口指令。不止响应,请求也需要类似的结构。 本来打算自己设计 TLV,接着发觉 ProtoBuf 就是此结构、现成的轮子,完全适合用来做这件事,各语言支持等也不错。 diff --git a/docs/document/level-0/ch07-xray-server.md b/docs/document/level-0/ch07-xray-server.md index 7d0d86a..46351a0 100644 --- a/docs/document/level-0/ch07-xray-server.md +++ b/docs/document/level-0/ch07-xray-server.md @@ -237,11 +237,10 @@ ], "outboundTag": "block" // 分流策略:交给出站"block"处理(黑洞屏蔽) }, - { // 3.2 防止服务器直连国内 + { + // 3.2 防止服务器直连国内 "type": "field", - "ip": [ - "geoip:cn" - ], + "ip": ["geoip:cn"], "outboundTag": "block" }, // 3.3 屏蔽广告 diff --git a/docs/en/development/protocols/vless.md b/docs/en/development/protocols/vless.md index 6530654..e4ff1b0 100644 --- a/docs/en/development/protocols/vless.md +++ b/docs/en/development/protocols/vless.md @@ -4,13 +4,13 @@ VLESS 是一个无状态的轻量传输协议,可以作为 Xray 客户端和 ## Request & Response -|1 字节|16 字节|1 字节|M 字节|1 字节|2 字节|1 字节|S 字节|X 字节| -|-|-|-|-|-|-|-|-|-| -|协议版本|等价 UUID|附加信息长度 M|附加信息 ProtoBuf|指令|端口|地址类型|地址|请求数据| +| 1 字节 | 16 字节 | 1 字节 | M 字节 | 1 字节 | 2 字节 | 1 字节 | S 字节 | X 字节 | +| -------- | --------- | -------------- | ----------------- | ------ | ------ | -------- | ------ | -------- | +| 协议版本 | 等价 UUID | 附加信息长度 M | 附加信息 ProtoBuf | 指令 | 端口 | 地址类型 | 地址 | 请求数据 | -|1 字节|1 字节|N 字节|Y 字节| -|-|-|-|-| -|协议版本,与请求的一致|附加信息长度 N|附加信息 ProtoBuf|响应数据| +| 1 字节 | 1 字节 | N 字节 | Y 字节 | +| ---------------------- | -------------- | ----------------- | -------- | +| 协议版本,与请求的一致 | 附加信息长度 N | 附加信息 ProtoBuf | 响应数据 | VLESS 早在第二个测试版 ALPHA 2 时就已经是上述结构了(BETA 是第五个测试版): @@ -35,7 +35,7 @@ https://github.com/XTLS/Xray-core/issues/158 似乎只有 VLESS 可选内嵌 ProtoBuf,它是一种数据交换格式,信息被紧密编码成二进制,TLV 结构(Tag Length Value)。 起因是我看到一篇文章称 SS 有一些缺点,如没有设计错误回报机制,客户端没办法根据不同的错误采取进一步的动作。 - (但我并不认同所有错误都要回报,不然防不了主动探测。下一个测试版中,服务器可以返回一串自定义信息。) +(但我并不认同所有错误都要回报,不然防不了主动探测。下一个测试版中,服务器可以返回一串自定义信息。) 于是想到一个可扩展的结构是很重要的,未来它也可以承载如动态端口指令。不止响应,请求也需要类似的结构。 本来打算自己设计 TLV,接着发觉 ProtoBuf 就是此结构、现成的轮子,完全适合用来做这件事,各语言支持等也不错。 diff --git a/docs/en/document/level-0/ch07-xray-server.md b/docs/en/document/level-0/ch07-xray-server.md index 1c1aa98..7a2764e 100644 --- a/docs/en/document/level-0/ch07-xray-server.md +++ b/docs/en/document/level-0/ch07-xray-server.md @@ -226,11 +226,10 @@ ], "outboundTag": "block" // 分流策略:交给出站"block"处理(黑洞屏蔽) }, - { // 3.2 防止服务器直连国内 + { + // 3.2 防止服务器直连国内 "type": "field", - "ip": [ - "geoip:cn" - ], + "ip": ["geoip:cn"], "outboundTag": "block" }, // 3.3 屏蔽广告