XTLS
Avoid annoying log
Integrity requirements
- [x] I confirm that I have read the documentation, understand the meaning of all the configuration items I wrote, and did not pile up seemingly useful options or default values.
- [x] I provided the complete config and logs, rather than just providing the truncated parts based on my own judgment.
- [x] I searched issues and did not find any similar issues.
- [x] The problem can be successfully reproduced in the latest Release
Description
I have been seeing disconnect connection without any reason , I have tested 10 different internets. Please follow up and find out what the problem is.
Reproduction Method
ws , xhttp
Client config
{
"log": {
"loglevel": "warning"
},
"inbounds": [
{
"tag": "socks",
"port": 10808,
"listen": "127.0.0.1",
"protocol": "socks",
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
],
"routeOnly": false
},
"settings": {
"auth": "noauth",
"udp": true,
"allowTransparent": false
}
}
],
"outbounds": [
{
"tag": "proxy",
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "ip",
"port": 65302,
"users": [
{
"id": "id",
"email": "[email protected]",
"security": "auto",
"encryption": "none"
}
]
}
]
},
"streamSettings": {
"network": "xhttp",
"xhttpSettings": {
"mode": "packet-up"
}
}
}
],
"routing": {
"domainStrategy": "AsIs",
"rules": [
]
}
}
Server config
{
"inbounds": [
{
"listen": null,
"port": 65302,
"protocol": "vless",
"settings": {
"clients": [
{
"email": "email",
"flow": "",
"id": "id"
}
],
"decryption": "none",
"fallbacks": []
},
"sniffing": {
"destOverride": [
"http",
"tls",
"fakedns",
"quic"
],
"enabled": true,
"metadataOnly": false,
"routeOnly": false
},
"streamSettings": {
"network": "xhttp",
"security": "none",
"xhttpSettings": {
"headers": {},
"host": "",
"mode": "packet-up",
"noSSEHeader": false,
"path": "/",
"scMaxBufferedPosts": 30,
"scMaxEachPostBytes": "1000000",
"xPaddingBytes": "100-1000"
}
},
"tag": "inbound-65302"
}
],
"log": {
"access": "none",
"dnsLog": false,
"error": "",
"loglevel": "warning",
"maskAddress": ""
},
"observatory": null,
"outbounds": [
{
"protocol": "freedom",
"settings": {
"domainStrategy": "UseIP",
"noises": [],
"redirect": ""
},
"tag": "direct"
},
{
"protocol": "blackhole",
"settings": {},
"tag": "blocked"
}
],
"policy": {
"levels": {
"0": {
"statsUserDownlink": true,
"statsUserUplink": true
}
},
"system": {
"statsInboundDownlink": true,
"statsInboundUplink": true
}
},
"reverse": null,
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"inboundTag": [
"api"
],
"outboundTag": "api",
"type": "field"
},
{
"ip": [
"geoip:private"
],
"outboundTag": "blocked",
"type": "field"
},
{
"outboundTag": "blocked",
"protocol": [
"bittorrent"
],
"type": "field"
}
]
},
"stats": {},
"transport": null
}
Client log
[Info] [2350440183] app/proxyman/inbound: connection ends > proxy/socks: connection ends > proxy/socks: failed to transport all TCP response > io: read/write on closed pipe
[Info] [3428991414] app/proxyman/outbound: app/proxyman/outbound: failed to process outbound traffic > proxy/vless/outbound: connection ends > proxy/vless/outbound: failed to transfer response payload > stream error: stream ID 1; INTERNAL_ERROR; received from peer
[Info] [2564370954] transport/internet/udp: failed to handle UDP input > io: read/write on closed pipe
[Info] [3795979941] app/proxyman/outbound: app/proxyman/outbound: failed to process outbound traffic > proxy/vless/outbound: connection ends > proxy/vless/outbound: failed to transfer response payload > proxy/vless/encoding: failed to read packet length > stream error: stream ID 3; INTERNAL_ERROR; received from peer
[Info] [4051956816] app/proxyman/inbound: connection ends > proxy/socks: connection ends > proxy/socks: failed to transport all TCP response > io: read/write on closed pipe
Server log
Invalid feedback
What do you need? I have sent the config and logs, you don't need my template either, you just need to check your xray client logs in debug
因为这并不是未按预期行为工作的BUG，你的问题里只有一句连不上，然后就没了。这个协议还是有人用的，如果设计真的有问题早炸锅了，我本次测试也没看到问题。对于这种含糊不清的描述除非有更多报告不然没啥精力单独给你解决
Because this is not a bug that does not work as expected. Your question only says that it cannot connect, and that's it. This protocol is still used by some people. If there is a problem with the design, it would have exploded long ago. I didn't see any problem in this test. For this kind of vague description, unless there are more reports, I don't have the energy to solve it for you separately.
Unfortunately, many users who are using it do not see this problem, apparently they have vision eye problems, apart from xhttp, this problem is also observed in websocket, what do you need now? Log? config ?
ws也有问题纯粹是你们网络的问题了 与核心无关
My network has no problems. I checked 10 internet companies.
I tested much older versions, they also have disconnectivity problems. I tested up to 1.8.15, the problem is very serious, please follow up @RPRX
Not Xray-core's bug
I run the xray client on a Hetzner, Oracle, and Alibaba server. After a few kilobytes, I see a disconnect error. The errors point to this and say that the connection was closed and could not send the rest to the server. Then it requested TCP again to open it. its normal?
If it is a code bug, there will be a lot of reports . Otherwise, it is just your configuration or other problems not related to the core. The issue area is only used to deal with bugs.
If you search the logs in the issue, you'll see that many people have had problems,
Web socket and xhttp are two transmissions that I tested, maybe other transmissions have problems too.
Monitor your connection logs for a few minutes and you will see that the logs are overflowing. I have tested with other people's configurations, different servers, and different people, and they all receive these logs.
Why should I receive a definitive log on a personal server after using a few kilobytes of Telegram or opening a Google site?
I know, dear R. Even though the disconnection log is coming up, I don't have any connection problems right now and I don't see any real disconnection, but I thought I'd let you know anyway.
There is also a problem with ws. It is purely a problem with your network and has nothing to do with the core. xhttp https://youtu.be/sfw-SMiby5g
If you see these videos, I will delete them.
I haven't sorted out the Xray-core logs yet. There may be a situation where the connection is normal but the log reports an error.~I've seen a lot~
It does not affect normal use and can be ignored.
Thank you for paying attention to everything.
举个例子，ray 默认五分钟无活动超时，可能就是粗暴的 close，然后因为层层解耦，有些协议还以为是非预期断开，就报错了
但是这都五分钟无活动了，肯定没有影响到你的正常使用
所以就 I don't have any connection problems right now and I don't see any real disconnection
What made me follow up was that Instagram, due to its low number of simultaneous connections, randomly experiences outages in the middle of videos between 30 min ~ 2 hours, and it takes about 30 to 40 seconds to resume playing the videos. After seeing the logs, I came to the conclusion that when these logs appear. By the way, I also have keep alive in all my configurations but not helped
By removing unnecessary logs, we will have a better understanding of the outage.