[Info] transport/internet/tcp: REALITY: processed invalid connection from <isp gate>:<random port> : failed to read client hello #5724

CharaVerKys · 2026-02-24T09:29:46Z

CharaVerKys
Feb 24, 2026

error appear on server side, client just common connect error
obviously tried:

updating xray
restarting
updating certificate (expired), tho i think xray not require ssl at all, and do not auto search for cert

obviously config im using was fine, and i used xray-core for 4 month already
2023-2024 issues for this error might be unrelated, havent found anything useful for me

i live in russia :sadface:

from home isp after some time of using vpn error starting to appear, after turning off and waiting, i can use vpn again
seems like DPI now (changing?) traffic, instead of just rejecting outcoming traffic
-not solved, just used vpn a little, just for sites like fandom.com or anything else that wont open, so no discord 3+ hours talks or high quality long vids on youtube

my server was unavailable from shitty isp on my work, and i was getting this error on vpn without working period
tried moving server to different ip, now it loads (havent waited for dns update tho), now i at least can access my git server
but vpn still not work

i just asking if anyone encountered this behavior lately..
and maybe, just maybe some one can actually help 🙏
i also tried reading tcp dumb, only see that server do receive some data, and for port 443 it do receive client hello packet, but cant answer against shitty isp or dpi ;; cant say more without knowing xray protocol underlines

here my configs:

charaverk | ~/xray_serv ~$ cat conf.json 
{
    "log": {
        "loglevel": "debug"
    },
    "inbounds": [
        {
            "listen":"0.0.0.0",
            "port": 444, // tried different ports from 1024 range (but not 443 btw) 
            "protocol": "vless",
            "settings": {
                "clients": [
                    {
                        "id": "no change since worked", 
                        "flow": "xtls-rprx-vision"
                    }
                ],
                "decryption": "none"
            },
            "streamSettings": {
                "network": "tcp",
                "security": "reality",
                "realitySettings": {
                    "dest": "google.com:443", 
                    "privateKey": "tried regenerating", 
                    "serverNames":["google.com"],
                    "shortIds": [
                        "8symbolsid"
                        //"0123456789abcdef" // 0 to f, length is a multiple of 2, maximum length is 16
                    ]
                }
            },
            "sniffing": {
                "enabled": true,
                "destOverride": [
                    "http",
                    "tls",
                    "quic"
                ],
                "routeOnly": true
            }
        }
    ],
    "outbounds": [
        {
            "protocol": "freedom",
            "tag": "direct"
        }
    ]
}

charaverk | ~/repos ~$ cat ../Public/conf.json 
{
    "log": {
        "loglevel": "debug"
    },
    "inbounds": [
        {
            "listen": "127.0.0.1", 
            "port": 1080,
            "protocol": "socks",
            "settings": {
                "udp": true
            },
            "sniffing": {
                "enabled": true,
                "destOverride": [
                    "http",
                    "tls",
                    "quic"
                ],
                "routeOnly": true
            }
        },
        {
            "listen": "127.0.0.1", 
            "port": 8080,
            "protocol": "http",
            "settings": {
                "udp": true
            },
            "sniffing": {
                "enabled": true,
                "destOverride": [
                    "http",
                    "tls",
                    "quic"
                ],
                "routeOnly": true
            }
        }
    ],
    "outbounds": [
        {
            "protocol": "vless",
            "settings": {
                "vnext": [
                    {
                        "address": "was my domain whole time, than i tried just (old) ip, and than, obviously, on new ip",
                        "port": 444, 
                        "users": [
                            {
                                "id": "...", // Needs to match server side
                                "encryption": "none",
                                "flow": "xtls-rprx-vision"
                            }
                        ]
                    }
                ]
            },
            "streamSettings": {
                "network": "tcp",
                "security": "reality",
                "realitySettings": {
                    "fingerprint": "chrome", 
                    "serverName": "google.com", // A website that support TLS1.3 and h2. If your dest is `1.1.1.1:443`, then leave it empty
                    "publicKey": "corresponding 'password' ", // run `xray x25519` to generate. Public and private keys need to be corresponding.
                    "spiderX": "", // If your dest is `1.1.1.1:443`, then you can fill it with `/dns-query/` or just leave it empty
                    "shortId": "..." // Required
                }
            },
            "tag": "proxy"
        }
    ]
}

for work, i need vpn for sites with data and chatbot for search
-btw, offtopic: ais are horrible at codding, but for search, when you not know where to look, for basic things like 'if such functional already exist' or 'what may be used' they are fine, big time savers (assuming checking info and doing further research)

whole (literally) xray server log:

charaverk | ~/xray_serv ~$ sudo ./xray -c conf.json 
Xray 26.2.6 (Xray, Penetrates Everything.) 12ee51e (go1.25.7 linux/amd64)
A unified platform for anti-censorship.
2026/02/24 08:31:49.825393 [Info] infra/conf/serial: Reading config: &{Name:conf.json Format:json}
2026/02/24 08:31:49.825501 [Debug] app/log: Logger started
2026/02/24 08:31:49.825509 [Debug] app/proxyman/inbound: creating stream worker on 0.0.0.0:444
2026/02/24 08:31:49.825522 [Info] transport/internet/tcp: listening TCP on 0.0.0.0:444
2026/02/24 08:31:49.825526 [Warning] core: Xray 26.2.6 started
2026/02/24 08:32:09.896002 [Info] transport/internet/tcp: REALITY: processed invalid connection from <ip>:40696: failed to read client hello
... repeat this for every tries, just feel screen with same string ...

versions of server and client match
client sample:

2026/02/24 12:21:03.172498 [Info] [1061322188] proxy/socks: TCP Connect request to tcp:duckduckgo.com:443
2026/02/24 12:21:03.173051 [Info] [1061322188] app/dispatcher: sniffed domain: duckduckgo.com
2026/02/24 12:21:03.173188 [Info] [1061322188] app/dispatcher: default route for tcp:duckduckgo.com:443
2026/02/24 12:21:03.173206 [Info] [1061322188] transport/internet/tcp: dialing TCP to tcp:meeee:444
2026/02/24 12:21:03.173216 [Debug] [1061322188] transport/internet: dialing to tcp:mee:444
2026/02/24 12:21:03.173102 from tcp:127.0.0.1:59758 accepted tcp:duckduckgo.com:443 [proxy]
... fires several other connects...
// there should've been timeout, but i waited for 5+ min, and there none...

CharaVerKys · 2026-02-24T11:00:31Z

CharaVerKys
Feb 24, 2026
Author

btw, work with random config
https://i.ibb.co/Y4GCK5Cb/Screenshot-from-2026-02-24-13-54-55.png
idk, should be just dpi/isp blocking incoming traffic from vps's data center

2 replies

ksnovich Feb 25, 2026

What does mean "work with random config" ? Did you fix issue with DPI? Can you explain please or show examples.

CharaVerKys Feb 26, 2026
Author

@ksnovich
have you followed screenshot?
nekoray, after scanning for available configs in list, give some working configs

when i tried last time extract xray config from nekoray and just use it with xray-core, it just not worked out, instead i bought server and used it for until this month, when i came back on workplace 3 weeks later, i started to getting this error on server side

not want to repeat what i already described above
it seems like they replace/reject some traffic on unknown for me rules

DiiButcher06 · 2026-07-12T10:42:00Z

DiiButcher06
Jul 12, 2026

I might have found something that significantly improved the stability of my VLESS + REALITY + XTLS Vision setup, so I wanted to share it in case it helps someone else.

For a long time my tunnel worked, but the client would repeatedly fail the initial handshake before eventually connecting. Sometimes I'd wait several minutes before traffic started flowing consistently. I spent quite a while checking UUIDs, keys, client settings, fingerprints, MTU, DNS, etc., but none of those made a noticeable difference.

The biggest improvement came from changing only the REALITY camouflage target (dest/serverNames).

Originally I was using:

"dest": "www.microsoft.com:443",
"serverNames": [
  "www.microsoft.com"
]

I switched to:

"dest": "www.cloudflare.com:443",
"serverNames": [
  "www.cloudflare.com"
]

(Credentials, UUID, keys and short IDs omitted intentionally.)

After restarting Xray, the difference was immediately noticeable:

Handshake failures virtually disappeared.
Connections became almost instantaneous.
The tunnel has remained stable under continuous use.
Mobile apps (WhatsApp, Instagram, Facebook, etc.) establish TLS sessions consistently without the repeated retries I was seeing before.

Server logs now look much healthier, with normal inbound requests followed by successful TLS detection and CopyRawConn splice:

proxy/vless/inbound: received request
XtlsFilterTls found tls client hello!
proxy/freedom: connection opened
XtlsFilterTls found tls 1.3
CopyRawConn splice

My setup is a standard VLESS + REALITY inbound with XTLS Vision. The only meaningful change was the camouflage target.

One additional detail: although REALITY itself doesn't require owning a domain, my VPS also has a domain whose DNS is managed by Cloudflare, with the DNS record set to DNS only (not proxied). I'm not claiming this is required or that it caused the improvement—it may simply be coincidental—but I'm mentioning it for completeness.

I'm not sure whether this behavior is specific to my ISP/region, routing, or something about the selected camouflage target, but in my environment changing the target from Microsoft to Cloudflare made a dramatic difference.

Has anyone else observed that some REALITY dest/serverNames combinations are noticeably more reliable than others? It would be interesting to know whether this is related to ISP routing, TLS fingerprinting, CDN behavior, or something else.

7 replies

CharaVerKys Jul 16, 2026
Author

yes, if reality is listening directly on port 443 your ip may get banned by some hosting providers, you can try adding Nginx in front of reality to route traffic using ssl-spread in the backend

it was NOT a hosting provider.
i was unable to connect only from ISP, VPS was working just fine elsewhere.
how tf you can run reality under nginx??? reality literally change tls client hello

louiskwt Jul 17, 2026

@DiiButcher06 thank you so much! changing the only the REALITY camouflage target (dest/serverNames) works!!

Basically, before changing camouflage target, everything is running and works fine but my laptop and iPhone clients just cannot connect to the server and the error message: transport/internet/tcp: REALITY: processed invalid connection pops up in my log. But after changing the dest/serverNames, those error messages disappear and my devices can finally connect to it.

I wonder why this is the case. But again, thanks sharing!

stormliucong Jul 18, 2026

It works for me. I got the same issue. my VPS is a droplet in NYC, so probably the specific Microsoft edge node my droplet reached may have behaved differently than the docs assume.

DiiButcher06 Jul 18, 2026

@CharaVerKys You are right, i did further studies, reality behind nginx breaks client hello, even with ssl spread. The issue for your ISP im not sure about, it might be their firewall.

CharaVerKys Jul 20, 2026
Author

@CharaVerKys You are right, i did further studies, reality behind nginx breaks client hello, even with ssl spread. The issue for your ISP im not sure about, it might be their firewall.

та какой фаервол
it is DPI - deep packet inspection
russian government just block all vpn they know

70% of the entire internet is unavailable from russia.

thats why i did my own vpn, this way no dpi know its signature.

zxcenigma · 2026-07-15T17:16:16Z

zxcenigma
Jul 15, 2026

I've been getting this problem for 2 days in a row, and it's solved in a very surprising way. I'm changing the dest to either microsoft or cloudflare :)
The problem is actually in the connection setup and handshake. Once the connection is established, there are no issues, and I'm using my session. However, the next session may encounter the same problem, requiring me to change the dest. It seems that these settings are being locked somewhere.

upd: i tried to enable my zapret with trying to start tls and its worked as well
upd2: i got some problems again and changed fingerprint with dest. The connection was established immediately

0 replies

Uh oh!

[Info] transport/internet/tcp: REALITY: processed invalid connection from <isp gate>:<random port> : failed to read client hello #5724

Uh oh!

CharaVerKys Feb 24, 2026

Replies: 3 comments · 9 replies

Uh oh!

CharaVerKys Feb 24, 2026 Author

Uh oh!

Uh oh!

ksnovich Feb 25, 2026

Uh oh!

CharaVerKys Feb 26, 2026 Author

Uh oh!

DiiButcher06 Jul 12, 2026

Uh oh!

CharaVerKys Jul 16, 2026 Author

Uh oh!

louiskwt Jul 17, 2026

Uh oh!

stormliucong Jul 18, 2026

Uh oh!

DiiButcher06 Jul 18, 2026

Uh oh!

Uh oh!

CharaVerKys Jul 20, 2026 Author

Uh oh!

Uh oh!

zxcenigma Jul 15, 2026

CharaVerKys
Feb 24, 2026

Replies: 3 comments 9 replies

CharaVerKys
Feb 24, 2026
Author

CharaVerKys Feb 26, 2026
Author

DiiButcher06
Jul 12, 2026

CharaVerKys Jul 16, 2026
Author

CharaVerKys Jul 20, 2026
Author

zxcenigma
Jul 15, 2026