目前，我使用了 Nginx 綁紮了 443 通訊埠，通過 ngx_stream_ssl_preread_module 檢查 SNI 並轉發到 VLESS 的通訊埠，我希望使 V2Ray 取得真實的用戶 IP，我嘗試在 xtlsSettings 中加入了

"acceptProxyProtocol": true

並在 Nginx 中設定

proxy_protocol  on;

但這樣並不能正常工作。
請問目前能夠支援或有計劃支援 Proxy Protocol 嗎

比如这些：

另能否提供一下xtls的协议说明文档？方便在其它语言里实现该协议。

..\github.com\xtls\go\key_schedule.go:46:12: undefined: hkdf.Expand
..\github.com\xtls\go\key_schedule.go:66:9: undefined: hkdf.Extract
..\github.com\xtls\go\key_schedule.go:114:30: undefined: curve25519.ScalarSize
..\github.com\xtls\go\key_schedule.go:118:21: undefined: curve25519.X25519
..\github.com\xtls\go\key_schedule.go:118:51: undefined: curve25519.Basepoint
..\github.com\xtls\go\key_schedule.go:194:20: undefined: curve25519.X25519

具体论证请参考
https://github.com/e1732a364fed/xtls-/blob/main/README.md

不一定对，只是希望大家都研究一下。

As stated in #6, I'm trying to package this library to debian/ubuntu, as this is a new dependency for v2ray.
However, the license is not compatible with other open ones.

While most files are BSD, file conn.go has a different license header attached, pointing to the LICENSE file.

And that one simply says "All rights reserved" and "Only for compiling executables usage for now.", which is clearly not BSD-style.
Could you kindly removing those statement, or working with us to think out a better plan for current one?
Thank you!

Dear developers,

As of the design of XTLS direct mode, the close_notify alert should not be sent to the server, this is done by checking if the record type is alert and the record length equals 31, this includes a 5-bytes record header and an inner content whose length is assumed to be 26 bytes.

However, the length of this inner content may vary, causing the record length to unequal to 31. Consequently, this record is sent to the server accidentally.

This makes the detection of XTLS unambiguously accurate since it's rare that some correctly implemented client sends an alert record before closing a TLS 1.3 stream.

Thanks for your work.

Your,
AkinoKaede

This attack is beyond the original threat model of XTLS. This issue is to discuss XTLS usage against more aggressive local adversaries like corporate firewalls.

There is an intrusive way to detect whether an encrypted TLS alert is close_notify: injecting binary garbage into the TCP connection. If an endpoint ignores the binary garbage, then it must have received a close_notify alert. XTLS parses the record but is not aware of the encrypted close_notify, so an active attacker can tell apart XTLS from other TLS stacks.

1. The user starts a huge download over HTTPS. Both Firefox and curl sends close_notify early during a download, so the attacker can begin after seeing the first 19-byte encrypted data.

2. The attacker forges TLS records and sends them to the XTLS server. XTLS forwards them to the actual server, who ignores them silently.

3. The attacker forges malformed TLS records. XTLS closes the connection immediately.

4. The attacker can now be sure of the existence of XTLS.

This attack is unlikely to be adopted by the GFW due to its potentially destructive effects. However, corporate networks might occasionally be aggressive enough to disrupt all TLS traffic. Direct mode is not a permanent solution: the mismatch between Client Hello extensions and the actual behavior easily spots a XTLS user.

客户端和服务端已更新4.29.0，使用的推荐配置，开启xtls
正常网站的tls抓包

xtls的抓包

都是从第一个包开始抓的

经实测，XTLS 在低性能或没有 AES 硬解的设备上效果出众，如在硬路由上换用 XTLS，同样跑满 CPU 时实现网速 翻倍，或是相同网速时 CPU 占用率减半
从第二个内层 TLS data record 开始，数据不二次加解密，直接转发，且从外面看还是一条连贯的普通 TLS

首先 感谢您的工作😊 然后请见谅 纯外行 就是喜欢瞎琢磨😀但是有时候想不通就很烦 。
按照个人理解 无论是socks5/http 还是透明代理(路由器、magisk模块等)中 由终端设备上的浏览器/APP发起的https连接的TLS(即内层TLS) 不都应该由终端本身浏览器/APP加解密吗

`

`

XTLS only supports TCP and DomainSocket for now. mkcp no supports?

Could you kindly provide a short description of this library?
I need it to package into Debian/Ubuntu. Thank you!

I was trying to build v2ray-core and caught some bugs:

~/go_projects/v2ray-core$ go test ./...

github.com/xtls/go/cpu

vendor/github.com/xtls/go/cpu/cpu_x86.s: Assembler messages:
vendor/github.com/xtls/go/cpu/cpu_x86.s:10: Error: no such instruction: text ·cpuid(SB),NOSPLIT,$0-24' vendor/github.com/xtls/go/cpu/cpu_x86.s:11: Error: junk (FP)' after expression
vendor/github.com/xtls/go/cpu/cpu_x86.s:11: Error: too many memory references for mov' vendor/github.com/xtls/go/cpu/cpu_x86.s:12: Error: junk (FP)' after expression
vendor/github.com/xtls/go/cpu/cpu_x86.s:12: Error: too many memory references for mov' vendor/github.com/xtls/go/cpu/cpu_x86.s:14: Error: too many memory references for mov'
vendor/github.com/xtls/go/cpu/cpu_x86.s:15: Error: too many memory references for mov' vendor/github.com/xtls/go/cpu/cpu_x86.s:16: Error: too many memory references for mov'
vendor/github.com/xtls/go/cpu/cpu_x86.s:17: Error: too many memory references for mov' vendor/github.com/xtls/go/cpu/cpu_x86.s:21: Error: no such instruction: text ·xgetbv(SB),NOSPLIT,$0-8'
vendor/github.com/xtls/go/cpu/cpu_x86.s:24: Error: too many memory references for mov' vendor/github.com/xtls/go/cpu/cpu_x86.s:25: Error: too many memory references for mov'

v2ray.com/core/external/github.com/cloudflare/sidh/internal/utils

external/github.com/cloudflare/sidh/internal/utils/cpuid_amd64.s: Assembler messages:
external/github.com/cloudflare/sidh/internal/utils/cpuid_amd64.s:5: Error: no such instruction: text ·cpuid(SB),NOSPLIT,$0-4' external/github.com/cloudflare/sidh/internal/utils/cpuid_amd64.s:6: Error: junk (FP)' after expression
external/github.com/cloudflare/sidh/internal/utils/cpuid_amd64.s:6: Error: too many memory references for mov' external/github.com/cloudflare/sidh/internal/utils/cpuid_amd64.s:7: Error: junk (FP)' after expression
external/github.com/cloudflare/sidh/internal/utils/cpuid_amd64.s:7: Error: too many memory references for mov' external/github.com/cloudflare/sidh/internal/utils/cpuid_amd64.s:9: Error: too many memory references for mov'
external/github.com/cloudflare/sidh/internal/utils/cpuid_amd64.s:10: Error: too many memory references for mov' external/github.com/cloudflare/sidh/internal/utils/cpuid_amd64.s:11: Error: too many memory references for mov'
external/github.com/cloudflare/sidh/internal/utils/cpuid_amd64.s:12: Error: too many memory references for `mov'

gollvm is used.
My release build.

CC @thanm @cherrymui

我使用了支持XTLS功能的v2ray-core（VLESS+TCP+TLS方式），在使用Chocolatey时，无法连接默认源。错误信息如下：

Error retrieving packages from source 'https://chocolatey.org/api/v2/':
 解密操作失败，请参见内部异常。

测试命令为choco install nodejs。

除此之外，暂未发现其他解密失败的情况。尝试过浏览器打开上述URL，没有问题。由于Chocolatey基于powershell，我又使用了powershell命令Invoke-WebRequest随便下载了一个文件，也没有问题。

看样子像是一个使用特定客户端或者访问特定网站才会发生的bug？