v2fly
Inconsistent connection failure
I know the title is generic but I dont know how else to describe it.
I have 3 v2ray servers working just fine with 0.5.29, with 0 issues. I've tried to setup 2 new ones, on Ubuntu 24 and CentOS8 and I ran into an issue I dont understand and dont know how to describe outside of - v2ray handshake(?)/initial connection simply fails randomly and it never recovers. Literally.
I start the server (terminal capture) I start the client.
I test the connection and... nothing. I restart the server 1-2 times and then start the client - it works.
Okay.
I set up cron for the server, reboot aaaaand... it is dead. No connection no matter how many times I restart the client.
I restart via terminal again, client immediately connects after a restart and open first target website... and then it dies and no more tunneling happens.
Like, this is literally it, this bizzare state of things. If you tell me how can I troubleshoot this I'd do it but otherwie I'm out if ideas.
Config and some client logs below:
LOGS and CONFIGS:
2025/09/30 03:02:05 [Warning] V2Ray 5.22.0 started
2025/09/30 03:02:12 [Info] [1795157184] proxy/socks: TCP Connect request to tcp:api.ipify.org:443
2025/09/30 03:02:12 [Warning] [1795157184] app/dispatcher: default route for tcp:api.ipify.org:443
2025/09/30 03:02:12 [Info] [1795157184] transport/internet/tcp: dialing TCP to tcp:33.133.33.1:49952
2025/09/30 03:02:12 [Info] [1795157184] proxy/vmess/outbound: tunneling request to tcp:api.ipify.org:443 via 33.133.33.1:49952
2025/09/30 03:02:32 [Info] [1795157184] app/proxyman/outbound: failed to process outbound traffic > proxy/vmess/outbound: connection ends > proxy/vmess/outbound: failed to read header > common/drain: common/drain: unable to drain connection > read tcp 192.168.1.2:52025->33.133.33.1:49952: wsarecv: An existing connection was forcibly closed by the remote host. > proxy/vmess/encoding: Unable to Read Header Len > read tcp 192.168.1.2:52025->33.133.33.1:49952: wsarecv: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
2025/09/30 03:02:32 [Info] [1795157184] app/proxyman/inbound: connection ends > proxy/socks: connection ends > proxy/socks: failed to transport all TCP response > io: read/write on closed pipe
2025/09/30 03:02:32 [Info] [4042078551] proxy/socks: TCP Connect request to tcp:api.ipify.org:443
2025/09/30 03:02:32 [Warning] [4042078551] app/dispatcher: default route for tcp:api.ipify.org:443
2025/09/30 03:02:32 [Info] [4042078551] transport/internet/tcp: dialing TCP to tcp:33.133.33.1:49952
2025/09/30 03:02:32 [Info] [4042078551] proxy/vmess/outbound: tunneling request to tcp:api.ipify.org:443 via 33.133.33.1:49952
config.json config_client.json Error.log
do your client use correct time?
Elaborate what does that mean. Server is UTC, mine is +3, time is synced on both. Again, it connects for the very first time, then dies
do your client use correct time?
Elaborate what does that mean. Server is UTC, mine is +3, time is synced on both. Again, it connects for the very first time, then dies
Some devices like Raspberry Pi have no battery on the motherboard.They will lose correct time after power off.(they have to update time every time they reboot) Correct time is necessary on both server and client when using VMess protocol.If not, connection will be refused by server. That's why I asked the earlier question.
I feel puzzled.The outbound port in "config_client.json" is "49952", but inbound port in "config.json" is "1080". Is that wrong? Or, you use another server to transfer data in the middle of the path?
It is a NAT serer, it always online there is no issues with time. Port is forwarded, I have similar setup on 3 more servers and it works just fine. But last 2 servers I've tried to set up all died with the same issue
Looks like shawdosocks+cloak is the only combination that works. Seems like they defeated v2ray and naked ss.
Looks like shawdosocks+cloak is the only combination that works. Seems like they defeated v2ray and naked ss.
I think you are right. I would like to share some experience with you. about half a year ago, I used the same config(I mean, single VMess protocol) as yours. I found that the single VMess protocol provided the low-bandwidth path through the Great Firewall.and after I transferred much data, the path was blocked by the Great Firewall. I guess, the Great Firewall is able to recognize and block the VMess protocol. what I did half a year ago was to add a TLS security layer outside the VMess.and now, the path works well. would you like to take a look at the config I am using?
Sure, wouldn't hurt
//config on client
//only outbounds object.I think it enough.
"outbounds": [
{
"protocol": "vmess",
"settings": {
"vnext": [
{
"address": "yourIP",
"port": 48932,
"users": [
{
"id": "yourID",
"alterId": 0,
"security": "auto"
}
]
}
]
},
"streamSettings": {
"network": "tcp",
"security": "tls",
"tlsSettings": {
"allowInsecure": true,
"serverName": "www.apple.com",
"fingerprint": "ios"
}
},
"tag": "proxy"
},
{
"protocol": "freedom",
"settings": {},
"tag": "direct"
}
]
//config on server
"inbounds": [
{
"port": 48932,
"protocol": "vmess",
"settings": {
"clients": [
{
"id": "yourID",
"level": 1,
"alterId": 0
},
{
"id": "anotherID I am using, not necessary for you",
"level": 1,
"alterId": 0
}
]
},
"streamSettings": {
"security": "tls",
"tlsSettings": {
"serverName": "www.apple.com",
"certificates": [
{
"certificateFile": "/etc/v2ray/ssl/v2ray.crt",
"keyFile": "/etc/v2ray/ssl/v2ray.key"
}
]
}
}
}
]
some tips:
The key configuration is in the "streamSettings" object. This enables the TLS security layer. You need to use a domain and a certificate. If you don't want to pay for domain and certificate(like me), use tools like OpenSSL on the server to generate the self-signed certificate. As for the "serverName" object, use any domain allowed by the Great Firewall. Don't forget to enable VMess "security" if you use a self-signed certificate, because a self-signed certificate is not secure enough. This config works well for me, but I'm not sure about you.
Feels like it isn't "open first target website" immediately by restarting the server side. But the browsers give up waiting unload metals and print out all the stuff that loaded successfully. Both Ubuntu24 and Centos8 are popular and modern distributions. Those os should work fine. Are you sure the two new servers have same network quality than the rest of three?
Or dns server on your client resolve an ip address that just optimizes for your region. Having low quality connection with your server.
@Kein V2ray will verify the certificate and the domain after enabling TLS when "allowInsecure" is false (default if not set). If I have purchased the domain and the certificate, everything will be fine. But I used the self-signed certificate(you know, for free), it will fail when V2ray verifies it. So I set "allowInsecure" = true to tell V2ray to ignore the verification. And, that's why the self-signed certificate is not secure enough.
@Kein Or, you can download your self-signed certificate to the client and add your self-signed certificate to the client's OS trusted certificate store. After that, your self-signed certificate will pass verification.
Your client config does not have an inbound (for example, socsk5 proxy) , how do you pass the traffic from client?
Your client config does not have an inbound (for example, socsk5 proxy) , how do you pass the traffic from client?
Sorry, read your old config file on the client or server. "inbounds" and other objects are already there. It's fine to reuse those old objects. My complete config file enables some modes like DNS and statistics. They are too long and not useful for you. So I showed you the part. I think that's enough.