xtls / xray-core Goto Github PK

Xray-core v1.0.0 was forked from v2fly-core 9a03cc5, and we have made & accumulated a huge number of enhancements over time, check the release notes for each version.
For third-party projects used in Xray-core, check your local or the latest go.mod.

Compilation

Windows (PowerShell)

$env:CGO_ENABLED=0
go build -o xray.exe -trimpath -ldflags "-s -w -buildid=" ./main

Linux / macOS

CGO_ENABLED=0 go build -o xray -trimpath -ldflags "-s -w -buildid=" ./main

Reproducible Releases

make

Stargazers over time

xray-core's People

Contributors

Stargazers

Watchers

Forkers

gossiper0305 devyujie lovewander juichao soundghost mainians xy588 zhu4ling3 wq0072 perfect-network cysk003 muzhi621 xwcoco blowfist le0liu feiyue789 wangzhiyong2019 rosebe tlanyan wtdg86ok oppops tawawhite july72k power-ful voncamel opemaspen gaoderby zorlei chengliyi isgasho baron01 zhongdabaicaide eyajfja wutaijieing ciring lzwpppp net-9qdv tpfeng justweee fadang123 kilolumen-v2ay wqm7749 schnappi-02 preventions dashigui destinyxt sunming11678 chancat87 454592673 vts163 wenjvqaq mobilefish nerokim vipwangqing konbar hublinux danielchen008 yoohooyoo rockstar2046 cosmoshua amibaworld n1un1u bado1a5a90 adfrog spysir godfo code871 iamlesile zjwster vpn-v2ray kinfaicheung sixu2018 m33ft tiger888198 element215 w995181185 syncyourmind uhtred009 qufuhq zhaoyadong00 jian108 arafac orz2233 u20024804 jasonchan-try forkism lucky0618 sunkissbearcn desertdd hk318 dandan7675 jjandnn 573462273 rocwang121 moodykeke juouyang overprince auroraxpm xxz296 wzwzaozao

xray-core's Issues

我发现大家都不用4MB的最新geosite规则，而只用最新的geoip规则，这是为什么？

请问大佬 mac和win 使用splice是不是无解了？以及将来有无xtls+splice+ws的计划？

RT，多谢，为了保护ip，长期稳定，套个袜子显得格外重要

无法用做Tor前置代理

Dec 13 14:14:57 hostname Tor[23859]:  12 connections died in state handshaking (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE
Dec 13 14:14:57 hostname Tor[23859]:  1 connections died in state handshaking (Tor, v3 handshake) with SSL state error in OPEN
Dec 13 14:15:04 hostname tor[23859]: Dec 13 14:15:04.000 [warn] Problem bootstrapping. Stuck at 14% (handshake): Handshaking with a relay. (TLS_ERROR; TLS_ERROR; count 14; recommendation warn; host HOSTIDHIDDE a>
Dec 13 14:15:04 hostname tor[23859]: Dec 13 14:15:04.000 [warn] 14 connections have failed:
Dec 13 14:15:04 hostname tor[23859]: Dec 13 14:15:04.000 [warn]  13 connections died in state handshaking (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE
Dec 13 14:15:04 hostname tor[23859]: Dec 13 14:15:04.000 [warn]  1 connections died in state handshaking (Tor, v3 handshake) with SSL state error in OPEN
Dec 13 14:15:04 hostname Tor[23859]: Problem bootstrapping. Stuck at 14% (handshake): Handshaking with a relay. (TLS_ERROR; TLS_ERROR; count 14; recommendation warn; host HOSTIDHIDDE at 95.217.167.152:443)
Dec 13 14:15:04 hostname Tor[23859]: 14 connections have failed:
Dec 13 14:15:04 hostname Tor[23859]:  13 connections died in state handshaking (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE
Dec 13 14:15:04 hostname Tor[23859]:  1 connections died in state handshaking (Tor, v3 handshake) with SSL state error in OPEN

torrc:

SOCKS5Proxy 127.0.0.1:1080

update:

服务端配置

{
    "log": {
        "loglevel": "debug"
    },
    "inbounds": [
        {
            "port": 443,
            "listen": "0.0.0.0",
            "protocol": "vless",
            "settings": {
                "decryption": "none",
                "clients": [
                    {
                        "id": "",
                        "flow": "xtls-rprx-direct"
                    }
                ],
                "fallbacks": [
                    {
                        "dest": 80
                    }
                ]
            },
            "streamSettings": {
                "network": "tcp",
                "security": "xtls",
                "xtlsSettings": {
                    "alpn": [
                        "http/1.1"
                    ],
                    "certificates": [
                        {
                            "keyFile": "/path/to/privkey.pem",
                            "certificateFile": "/path/to/fullchain.pem"
                        }
                    ]
                }
            }
        }
    ],
    "outbounds": [
        {
            "protocol": "freedom",
            "settings": {}
        },
        {
            "protocol": "blackhole",
            "settings": {},
            "response": {
                "type": "http"
            },
            "tag": "blocked"
        }
    ],
    "routing": {
        "strategy": "rules",
        "settings": {
            "rules": [
                {
                    "type": "field",
                    "ip": [
                        "0.0.0.0/8",
                        "10.0.0.0/8",
                        "100.64.0.0/10",
                        "127.0.0.0/8",
                        "169.254.0.0/16",
                        "172.16.0.0/12",
                        "192.0.0.0/24",
                        "192.0.2.0/24",
                        "192.168.0.0/16",
                        "198.18.0.0/15",
                        "198.51.100.0/24",
                        "203.0.113.0/24",
                        "::1/128",
                        "fc00::/7",
                        "fe80::/10"
                    ],
                    "outboundTag": "blocked"
                },
                {
                    "type": "field",
                    "protocol": [
                        "bittorrent"
                    ],
                    "outboundTag": "blocked"
                }
            ]
        }
    }
}

客户端配置

{
    "log": {
        "loglevel": "warning"
    },
    "inbounds": [
        {
            "listen": "0.0.0.0",
            "port": 1080,
            "protocol": "socks",
            "sniffing": {
                "enabled": true,
                "destOverride": [
                    "http",
                    "tls"
                ]
            },
            "settings": {
                "auth": "noauth",
                "udp": true
            },
            "tag": "in"
        }
    ],
    "outbounds": [
        {
            "protocol": "vless",
            "settings": {
                "vnext": [
                    {
                        "address": "some.tld",
                        "port": 443,
                        "users": [
                            {
                                "id": "",
                                "flow": "xtls-rprx-direct",
                                "encryption": "none",
                                "level": 0
                            }
                        ]
                    }
                ]
            },
            "streamSettings": {
                "network": "tcp",
                "security": "xtls",
                "xtlsSettings": {
                    "serverName": "some.tld"
                }
            },
            "tag": "out"
        }
    ],
    "routing": {
        "settings": {
            "domainStrategy": "IPIfNonMatch",
            "rules": []
        },
        "strategy": "rules"
    }
}

服务端日志

2020/12/13 15:04:47 [Info] [2038793195] app/proxyman/outbound: failed to process outbound traffic > proxy/freedom: failed to open connection to tcp:www.qhes3ymaudanamzulm4fkae6.com:443 > common/retry: [dial tcp: lookup www.qhes3ymaudanamzulm4fkae6.com on 10.0.2.3:53: no such host] > common/retry: all retry attempts failed
2020/12/13 15:04:47 [Info] [2038793195] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > io: read/write on closed pipe
2020/12/13 15:04:47 [Info] [3279632750] app/proxyman/outbound: failed to process outbound traffic > proxy/freedom: failed to open connection to tcp:www.4lvzvgwmfm5.com:443 > common/retry: [dial tcp: lookup www.4lvzvgwmfm5.com on 10.0.2.3:53: no such host] > common/retry: all retry attempts failed
2020/12/13 15:04:47 [Info] [3279632750] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > io: read/write on closed pipe

1.1.2 使用xtls 只要config中出现mux设定就会无法执行

使用qv2ray搭配1.1.2版xray核心+xtls（其他版本没尝试过）只要enable mux就会出现
Configuration Error "[Info] main/jsonem: Reading config: C:/Users/admin/AppData/Local/qv2ray/generated/config.gen.json"
V2Ray kernel failed to start
在openwrt x86使用shadowsocksr+中使用1.1.2 core+xtls，因为ssr+会自己把mux:false加到设定档中同样会造成1.1.2 xray core无法启动，只有在config中将mux删除才能启动1.1.2版xray

add github ci for building binaries

https://github.com/v2fly/v2ray-core/blob/master/.github/workflows/release.yml

[feature request] request docker distribution support

Add distribution for hub.docker.com plz.

Splice won't apply to Android.

#6 goos=android for Android is needed.

Xray-core/infra/conf/vless.go

Lines 172 to 175 in 16544c1

    
           case "xtls-rprx-splice", "xtls-rprx-splice-udp443": 
        
           	if runtime.GOOS != "linux" { 
        
           		return nil, newError(`VLESS users: "` + account.Flow + `" only support linux in this version`) 
        
           	}

请问如何指定配置文件路径以及验证配置文件的正确性

如题，我通过help查看了相关信息。并没有找到这样的选项

API流量统计功能不能用

# /usr/local/bin/xray api --server=127.0.0.1:10010 StatsService.QueryStats 'pattern: "" reset: false'
   failed to call service StatsService.QueryStats

结果如上。。

反向代理没法正常运行

按照此方法设置反向代理，配置完全一致。
https://guide.v2fly.org/app/reverse2.html#b-%E7%9A%84%E9%85%8D%E7%BD%AE
v2ray-core 4.32.1 可以成功运行。

在服务器B上Xray-core v1.1.1 运行error.log报错如下
app/reverse: failed to process reverse connection > common/mux: unable to find an available mux client

启动时能印出基本讯息吗？

像是local ip/port、remote ip/port，tls or xtls之类的，才知道目前的client<->server是使用tls或xtls，direct或origin。

另外能否socks5/http port共用，像gost一样，也省了安装http->socks5的proxy。

Xray 1.1.3 Vless XTLS splice失效

RT，1.1.2中客户端采用splice，服务端direct.服务端与客户端升级至1.1.3 同样的配置不变无法连接了。

xr.exe改名为v2ray.exe在v2rayN使用。设置里开启MUX不选，就连接失败。

我是把xr.exe改名为v2ray.exe，放在v2rayN中使用。

这时候在v2rayn的设置里，开启MUX选项，是选中，生成的config文件中，MUX值是false。正常代理，可以打开网页。

在v2rayn的设置里，开启MUX选项，不选中，生成的config文件中，MUX是false。连接失败，不能打开网页。

能否考虑用tar.xz打包linux的安装包？

xray安装包压缩后

zip格式：8.03MB
xz格式：5.32MB

xz只有zip的2/3大小

现在linux打包挺多用xz格式的

客户端偶尔会CPU

fallbacks在核心内部不通过tcp或者domainsocket传输的可能性？

如题，目前fallbacks只能通过tcp或者domainsocket，而这不可避免地带来性能损失。如果fallbacks的目标为核心的另外一个inbound，是否有实现直接在核心内部传输的可能性？
关于配置文件配置文件部分，我首先想到的是使用原本就有的tag标签，然后增加给dest指定tag的功能
比如这个配置https://github.com/v2fly/v2ray-examples/blob/master/VLESS-TCP-TLS-WS%20(recommended)/config_server.json
可以修改为：

{
    "log": {
        "loglevel": "warning"
    },
    "inbounds": [
        {
            "port": 443,
            "protocol": "vless",
            "settings": {
                "clients": [
                    {
                        "id": "", // 填写你的 UUID
                        "level": 0,
                        "email": "[email protected]"
                    }
                ],
                "decryption": "none",
                "fallbacks": [
                    {
                        "dest": 80
                    },
                    {
                        "path": "/websocket", // 必须换成自定义的 PATH
                        "dest": "tag:websocket",
                    }
                ]
            },
            "streamSettings": {
                "network": "tcp",
                "security": "tls",
                "tlsSettings": {
                    "alpn": [
                        "http/1.1"
                    ],
                    "certificates": [
                        {
                            "certificateFile": "/path/to/fullchain.crt", // 换成你的证书，绝对路径
                            "keyFile": "/path/to/private.key" // 换成你的私钥，绝对路径
                        }
                    ]
                }
            }
        },
        {
            "tag": "websocket",
            "protocol": "vless",
            "settings": {
                "clients": [
                    {
                        "id": "", // 填写你的 UUID
                        "level": 0,
                        "email": "[email protected]"
                    }
                ],
                "decryption": "none"
            },
            "streamSettings": {
                "network": "ws",
                "security": "none",
                "wsSettings": {
                    "path": "/websocket" // 必须换成自定义的 PATH，需要和上面的一致
                }
            }
        }
    ],
    "outbounds": [
        {
            "protocol": "freedom"
        }
    ]
}

请问有没有计划添加可以直接使用的增删用户的api命令？

像流量统计那样可以直接使用的api命令
多谢

哇，发生了什么~光速版v2ray诞生了

我要给作者一个大大的👍

👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏👏

客户端用旧版v2ray 4.32.1可以和xray服务端兼容不？

主要是现在主流客户端软件集成的还是v2ray

xray v1.0 不支持打标记吗

根据 v2ray 官方文档设置透明代理，给每个 Outbound 打标记

"streamSettings": {
"network": "tcp",
"sockopt": {
"mark": 255
},

iptables -t nat -A OUTPUT -p tcp -m mark --mark 0xff -j RETURN

同样的配置，在 v2ray v4.33 版本下正常，通过 iptables 能看到捕获的数据包数量
而在 xray 下看不到捕获的数据数量

AC86U运行Xray-linux-arm64-v8a报错out of memory

@RT-AC86U-A9E0:/tmp/home/root# uname -a
Linux RT-AC86U-A9E0 4.1.27 #2 SMP PREEMPT Fri Aug 14 16:38:14 EDT 2020 aarch64 ASUSWRT-Merlin

@RT-AC86U-A9E0:/tmp/home/root# free -m
total used free shared buffers cached
Mem: 440368 240308 200060 38272 0 53572
-/+ buffers/cache: 186736 253632
Swap: 0 0 0

@RT-AC86U-A9E0:/tmp/home/root# ./ray
fatal error: runtime: out of memory

runtime stack:
runtime.throw(0x9a4be7, 0x16)
runtime/panic.go:1116 +0x54 fp=0x7ff895cc60 sp=0x7ff895cc30 pc=0x41714
runtime.sysMap(0x4000000000, 0x4000000, 0x105dd38)
runtime/mem_linux.go:169 +0xbc fp=0x7ff895cca0 sp=0x7ff895cc60 pc=0x2686c
runtime.(*mheap).sysAlloc(0x10417a0, 0x400000, 0x7ff895cdb8, 0x3501c)
runtime/malloc.go:727 +0x188 fp=0x7ff895cd50 sp=0x7ff895cca0 pc=0x1b3b8
runtime.(*mheap).grow(0x10417a0, 0x1, 0x0)
runtime/mheap.go:1344 +0x80 fp=0x7ff895cdc0 sp=0x7ff895cd50 pc=0x35250
runtime.(*mheap).allocSpan(0x10417a0, 0x1, 0x2a00, 0x105dd48, 0x0)
runtime/mheap.go:1160 +0x5ec fp=0x7ff895ce40 sp=0x7ff895cdc0 pc=0x3504c
runtime.(*mheap).alloc.func1()
runtime/mheap.go:907 +0x60 fp=0x7ff895cea0 sp=0x7ff895ce40 pc=0x6a620
runtime.(*mheap).alloc(0x10417a0, 0x1, 0x7ff895012a, 0x25f44)
runtime/mheap.go:901 +0x64 fp=0x7ff895cef0 sp=0x7ff895cea0 pc=0x34674
runtime.(*mcentral).grow(0x1054658, 0x0)
runtime/mcentral.go:506 +0x74 fp=0x7ff895cf40 sp=0x7ff895cef0 pc=0x262b4
runtime.(*mcentral).cacheSpan(0x1054658, 0x1cd18)
runtime/mcentral.go:177 +0x41c fp=0x7ff895cfd0 sp=0x7ff895cf40 pc=0x2600c
runtime.(*mcache).refill(0x7f8d62e108, 0x2a)
runtime/mcache.go:142 +0xbc fp=0x7ff895d000 sp=0x7ff895cfd0 pc=0x2596c
runtime.(*mcache).nextFree(0x7f8d62e108, 0xffffffffffffff2a, 0x105b178, 0x102a240, 0x7ff895d098)
runtime/malloc.go:880 +0x8c fp=0x7ff895d050 sp=0x7ff895d000 pc=0x1badc
runtime.mallocgc(0x180, 0x991c80, 0x7ff895d101, 0x7ff895d158)
runtime/malloc.go:1061 +0x6b4 fp=0x7ff895d110 sp=0x7ff895d050 pc=0x1c324
runtime.newobject(0x991c80, 0x45078)
runtime/malloc.go:1195 +0x38 fp=0x7ff895d140 sp=0x7ff895d110 pc=0x1c738
runtime.malg(0x8000, 0x0)
runtime/proc.go:3514 +0x2c fp=0x7ff895d190 sp=0x7ff895d140 pc=0x4c07c
runtime.mpreinit(0x102a240)
runtime/os_linux.go:340 +0x28 fp=0x7ff895d1b0 sp=0x7ff895d190 pc=0x3ee68
runtime.mcommoninit(0x102a240, 0xffffffffffffffff)
runtime/proc.go:663 +0xdc fp=0x7ff895d200 sp=0x7ff895d1b0 pc=0x4519c
runtime.schedinit()
runtime/proc.go:565 +0xa4 fp=0x7ff895d270 sp=0x7ff895d200 pc=0x44cf4
runtime.rt0_go(0x7ff895de47, 0x0, 0x7ff895de4d, 0x7ff895de70, 0x7ff895de7f, 0x7ff895deaa, 0x7ff895deb2, 0x7ff895debd, 0x7ff895ded0, 0x7ff895dee0, ...)
runtime/asm_arm64.s:69 +0xb4 fp=0x7ff895d2a0 sp=0x7ff895d270 pc=0x70cf4

[Features Request] Add location asset search for V2Ray

https://github.com/XTLS/Xray-core/blob/main/common/platform/others.go

for _, p := range []string{
		defPath,
		filepath.Join("/usr/local/share/xray/", file),
		filepath.Join("/usr/share/xray/", file),
	} {
		if _, err := os.Stat(p); os.IsNotExist(err) {
			continue
		}

		// asset found
		return p
	}

可以看出目前 Xray-core 會自動尋找 /usr/local/share/xray/ 和 /usr/share/xray/ 作為資源路徑。

這讓我為 Arch Linux 打包時造成了一定的困惑
目前 AUR 中採用 v2ray-domain-list-community 和 v2ray-geoip 作為依賴項，並在 service 文檔中設置環境變量 XRAY_LOCATION_ASSET=/usr/share/v2ray。
Arch Linux CN 方面則是打包了 xray-domain-list-community 和 xray-geoip。
但目前來看，兩種方法或許都不是最佳解決方案。
或許可以添加以下代碼在第32行之後

filepath.Join("/usr/local/share/v2ray/", file),
filepath.Join("/usr/share/v2ray/", file),

Can a XTLS fallback to another XTLS ?

是否支持homebrew安装xray-core?

希望能使用homebrew安装xray-core, 请问会提供这样的github repo以供brew cask install吗?

[Features Request] Request QUIC with XTLS support

TL;DR 因为 mkcp 已经有xtls支持，不知道后续是否会有对QUIC的xtls支持？

QUIC在一定程度上能够抵抗丢包（软件控制重发包），并且随着未来HTTP3的普及被混淆于海量流量中，可能会比mkcp更安全/特征更小（之前被秒封有心理阴影了）。同时鉴于mkcp与QUIC都是基于UDP的协议，之前在VLESS发布时说暂时无法支持，但现在mkcp已经在 v2fly/v2ray-core#266 中讨论过并且已经实现，就不知同样的对QUIC添加支持是否有技术可行性？

辛苦大佬啦！

First

占个位

任意门 tproxy 模式无法透明代理 IPv6 TCP

配置文件见 v2fly/v2ray-core#320
客户端，服务端均为 Xray 1.1.2

IPv6 TCP 无法代理，出现以下错误

2020/12/08 08:00:59 [Info] transport/internet/tcp: failed to call getsockopt > no such file or directory
2020/12/08 08:00:59 [Info] [1507096704] app/proxyman/inbound: failed to get original destination > transport/internet/tcp: failed to call getsockopt
2020/12/08 08:00:59 [Debug] [1507096704] proxy/dokodemo: processing connection from: [隐藏]:51500
2020/12/08 08:00:59 [Info] [1507096704] app/proxyman/inbound: connection ends > proxy/dokodemo: unable to get destination

IPv6 UDP 正常

2020/12/08 08:03:43 [Debug] transport/internet/udp: UDP original destination: udp:[2001:4860:4860::8888]:53
2020/12/08 08:03:43 [Debug] [3285941684] proxy/dokodemo: processing connection from: [隐藏]:60665
2020/12/08 08:03:43 [Info] [3285941684] proxy/dokodemo: received request for [隐藏]:60665
2020/12/08 08:03:43 [Info] [3285941684] app/dispatcher: default route for udp:[2001:4860:4860::8888]:53
2020/12/08 08:03:43 [Info] [3285941684] transport/internet/tcp: dialing TCP to tcp:隐藏:443
2020/12/08 08:03:43 [隐藏]:60665 accepted udp:[2001:4860:4860::8888]:53
2020/12/08 08:03:43 [Info] [3285941684] proxy/vless/outbound: tunneling request to udp:[2001:4860:4860::8888]:53 via tcp:隐藏:443

关于标准分享链接的疑问？

当下时间已经来到2077年，我觉得可以公布一些分享链接的标准的草案或者预想，以便进行”预“开发

1.分享链接将采用/基于什么语言？简化的json，或其超集YAML 或是其他？

2.分享链接是否会像某些软件的分享链接用base64做“伪”加密？

3.对于采用Xray-core的客户端，是否会要求必须采用此链接标准？或是仅要求能够读取此链接？

4.是否要求采用Xray-core的客户端能够被标准分享链接的URLScheme唤醒和添加？

do Not hardcode version name

thanks for your contributions in advanced.

could you do NOT hardcode versionName v1 at packageName github.com/xtls/xray-core/v1 as changed to github.com/xtls/xray-core as we could be easy to move for possible version/repo v2.

// now
import "github.com/xtls/xray-core/v1/core"

// instead
import "github.com/xtls/xray-core/core"

xray性能果然提升巨大

@RPRX 加油，谢谢！

速度有很大的提升，感谢作者

客户端偶尔会CPU占用率持续居高不下

具体什么原因还没有跟进，也许大家都可以关注下看看是不是特例

在一台CPU是i5-9400T的PVE上面做得网关透明代理，debian10

偶尔用HTOP查看xray进程的cpu占用达到200-300%，而且会长时间持续，直到重启服务
遇到过2次

另外一台CPU是E3-1265L的PVE暂时还没发现这个现象

请问SSR+能支持Xray嘛？

能让SSR+支持Xray嘛？比如模拟成v2ray

Python

建议更换ws库为GOWebsockets，提升性能，减少资源

参见文章https://yalantis.com/blog/how-to-build-websockets-in-go/
或者参见下面文档，作者是如何提升ws性能，减少资源占用的
1m connections for websocket.pdf

容易记的安装脚本

可以使用下面命令安装

bash <(curl xray.sh)

直接访问 Xray.sh 可以显示安装次数

https://xray.sh

初版，后面可能加点儿其他功能

调用官方的安装脚本

$script = file_get_contents('https://raw.githubusercontent.com/XTLS/Xray-install/main/install-release.sh');
header('Content-Type: application/force-download');
header('Content-Disposition: inline; filename="install-release.sh"');
echo $script;

是否会建设类似v2fly.org的文档网站？

关于xver的问题

关于回落设置，发现一个问题，如果在fallbacks里面设置了xver，回落到本机上的websocket就不正常，服务端返回为"invalid request version"，去掉xver就正常了，具体配置如下：
{
"log": {
"loglevel": "warning"
},
"inbounds": [
{
"listen": "0.0.0.0",
"port": 443,
"protocol": "vless",
"settings": {
"clients": [
{
"id": "af0eab97-85e2-46ac-ac23-da430b5b7ef1",
"level": 0,
"email": "[email protected]",
"flow":"xtls-rprx-direct"
}
],
"decryption": "none",
"fallbacks": [
{
"path": "/ray",
"dest": 17777,
"xver": 1
},
{
"dest": 17666
}
]
},
"streamSettings": {
"network": "tcp",
"security": "xtls",
"xtlsSettings": {
"serverName": "example.com",
"alpn": [
"h2",
"http/1.1"
],
"certificates": [
{
"certificateFile": "/etc/xray/cert/fullchain.cer",
"keyFile": "/etc/xray/cert/private.key"
}
]
}
}
},
{
"port": 17777,
"listen": "127.0.0.1",
"protocol": "vless",
"settings": {
"clients": [
{
"id": "69065602-0043-4b2b-b743-7c67fb8482dc",
"level": 0,
"email": "[email protected]"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "ws",
"security": "none",
"wsSettings": {
"path": "/ray"
}
}
}
],
"outbounds": [
{
"protocol": "freedom",
"settings": { }
}
]
}

命令行启动xray成功，但systemd 启动xray失败

server端
用命令行启动xray
sudo /usr/local/bin/xray run -config /usr/local/etc/xray/config.json
成功可以得到
2020/11/29 22:51:58 [Info] github.com/xtls/xray-core/v1/main/jsonem: Reading config: /usr/local/etc/xray/config.json

但是用systemd 启动则会失败
sudo systemctl start xray.service
sudo systemctl status xray.service

● xray.service - Xray Service
    Loaded: loaded (/etc/systemd/system/xray.service; disabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/xray.service.d
             └─10-donot_touch_single_conf.conf
     Active: failed (Result: exit-code) since Sun 2020-11-29 22:48:55 UTC; 1min 36s ago
       Docs: https://github.com/xtls
    Process: 1358 ExecStart=/usr/local/bin/xray run -config /usr/local/etc/xray/config.json >
   Main PID: 1358 (code=exited, status=1/FAILURE)

Nov 29 22:48:55 ciacconas-ubuntu systemd[1]: xray.service: Main process exited, code=exited,>
Nov 29 22:48:55 ciacconas-ubuntu systemd[1]: xray.service: Failed with result 'exit-code'.
Nov 29 22:48:55 ciacconas-ubuntu systemd[1]: xray.service: Scheduled restart job, restart co>
Nov 29 22:48:55 ciacconas-ubuntu systemd[1]: Stopped Xray Service.
Nov 29 22:48:55 ciacconas-ubuntu systemd[1]: xray.service: Start request repeated too quickl>
Nov 29 22:48:55 ciacconas-ubuntu systemd[1]: xray.service: Failed with result 'exit-code'.
Nov 29 22:48:55 ciacconas-ubuntu systemd[1]: Failed to start Xray Service.

这是什么问题呀？我的config就是复制的官方的examples

如何自定义ID

配置文件在哪个目录。谢谢

优化内存占用

哥，后面会有xctl吗？发现内置json一启动就占用将近80M内存，openwrt有点吃不消。

1.0

4.32.1

xray core

Xray, Penetrates Everything. Also the best v2ray-core, with XTLS support. Fully compatible configuration.

Xray core

Xray, Penetrates Everything. Also the best v2ray-core, with XTLS support. Fully compatible configuration.

xray 1.1.1 linux服务端systemd服务启动失败

升级之前使用的是1.0.0版本运行正常，配置模型为nginx + ws 反代
升级到1.1.1，准备试试xtls，于是修改服务端配置，参考这个写的：
https://github.com/v2fly/v2ray-examples/blob/master/VLESS-TCP-TLS-WS%20(recommended)/config_server.json
启动失败后，定位如下：
1，怀疑是配置问题，但是通过命令行启动没问题，通过 xray run -test 配置，也无问题
2，精简配置到最简单仍不行
3，修改systemd配置文件，使用root用户或者nobody用户启动均失败
4，最后xray换回1.0.0正常。
查看journalctl 日志如下：

Dec 04 15:13:39 serverx xray[24215]: Xray 1.1.1 (Xray, Penetrates Everything.) Custom (go1.15.6 linux/amd64)
Dec 04 15:13:39 serverx xray[24215]: A unified platform for anti-censorship.
Dec 04 15:13:39 serverx xray[24215]: Filed to start: %!s(PANIC=Error method: runtime error: slice bounds out of range [26:4])
Dec 04 15:13:39 serverx systemd[1]: xray.service: Main process exited, code=exited, status=1/FAILURE
Dec 04 15:13:39 serverx systemd[1]: xray.service: Failed with result 'exit-code'.
Dec 04 15:13:40 serverx systemd[1]: xray.service: Service RestartSec=100ms expired, scheduling restart.
Dec 04 15:13:40 serverx systemd[1]: xray.service: Scheduled restart job, restart counter is at 5.
Dec 04 15:13:40 serverx systemd[1]: Stopped Xray Service.

v2ray-core中为什么移除xtls

挺好用的功能，是因为什么？

trojan的splice不能正常启用

服务器配置

"inbounds": [
{
"port": 443,
"protocol": "trojan",
"settings": {
"clients": [
{
"password": "*****",
"flow": "xtls-rprx-direct"
}
],

客户端配置

"outbounds": [
{
"mux": {
"concurrency": -1,
"enabled": false
},
"protocol": "trojan",
"settings": {
"servers": [
{
"address": "",
"level": 8,
"password": "",
"port": 443,
"flow": "xtls-rprx-splice"
}
]
},
"streamSettings": {
"security": "xtls",
"xtlsSettings": {
"allowInsecure": true,
"serverName": "***"
}
},
"tag": "proxy"
},

调试显示信息

XTLS DirectOut = true
XTLS DirectOut = true
XTLS DirectOut = true
XTLS DirectPre = true
XTLS DirectIn = true
XTLS ReadV
XTLS DirectPre = true
XTLS DirectIn = true

后续更新：#56

CPU多核

是否启用多核
- 旧版本的v2ray可能存在此问题
- 确认go1.5以后自动启用多核,不需要再通过代码获取核心数和指定max可用核心数量
- 根据上一条,xray应不存在多核利用问题.
- 未确定指定更多(高于实际核心数量)的CPU核心数是否会提升效率
- 参考link

内存占用

VIRT高(4G)
- 不是问题,go程序本身即如此
- 参考link
~~启动占用内存正常为20M,部分架构(似乎仅arm64)为80M~~(已破案,#68)
- 历史遗留问题,v2ray4.32.0后开始出现此问题.
- ~~基本确定可能原因为jsonem造成,待修改测试~~(已破案,#68)
kcp占用内存
- 历史遗留问题,确定kcp内存释放缓慢(测试及gole报告),其他模式可立即释放内存
- kcp本身运行时占用内存较高(和配置的数值有关,因为决定发包倍率)
- xray以后更让上面两个问题暴露(与以前v2ray相同配置参数时,buffer size 更大导致OOM)

splice(XTLS)

~~部分用户反映splice比direct慢~~ 已解决，看楼下
- 是因为在内核中设置 net.ipv6.conf.all.forwarding=1 或者 net.ipv4.ip_forward=1 造成
- 详细可点击此处破案系列之三
- ~~可能原因:sleep,内核,都待验证.~~ 基本可以确定是 sleep 一毫秒导致
- ~~在splice/XTLS测试中发现的问题:设置handshake值>测试时长,且指定带宽上限时,测试完成链接不断开.未知原因以及是否因此对用户测试也造成影响.~~ 此处现象并不明确,待更多测试确认不断开状况.

	case "xtls-rprx-splice", "xtls-rprx-splice-udp443":
	if runtime.GOOS != "linux" {
	return nil, newError(`VLESS users: "` + account.Flow + `" only support linux in this version`)
	}

xtls / xray-core Goto Github PK

xray-core's Introduction

Project X

License

Documentation

Telegram

Installation

Usage

GUI Clients

Others that support VLESS, XTLS, REALITY, XUDP, PLUX...

Contributing

Credits