Russia: widespread VLESS outages due to TLS handshake blocking/degradation — request TLS/transport hardening and anti-probing

Hello Xeovo Team,

Some users in Russia have been experiencing consistent connection failures on VLESS profiles that use TLS transport (e.g., VLESS+TLS / VLESS+TCP+TLS). In practice it looks like the blocking/degradation targets the TLS layer (handshake) rather than VLESS itself: the TLS session fails to establish or gets terminated very early, so VLESS cannot come up.

Given the current wave of DPI/TSPU filtering changes in Russia, this behavior matches reports where TLS handshakes are interfered with (including potential ClientHello tampering or aggressive fingerprinting). I am asking you to harden your TLS/transport setup and provide updated client profiles.

Please implement the changes below on your side and share updated configurations.

⸻

1) Bring TLS closer to a normal “web-like” profile (required)
1. Use only a publicly trusted certificate (ACME/Let’s Encrypt or equivalent) for a real domain, with a valid full chain. Avoid self-signed or unusual chains.
2. Ensure strict consistency between SNI ↔ certificate ↔ destination domain. Any mismatch increases the likelihood of detection or blocking.
3. Enable standard ALPN values: h2 and http/1.1.
4. Keep TLS 1.3 enabled and avoid exotic cipher suites or non-standard TLS extensions.

⸻

2) Add anti-probing behavior and proper fallbacks on port 443 (required)

To avoid active probing/scanning revealing a proxy service:
• Port 443 should serve a normal HTTPS website (e.g., Nginx/Caddy).
• Xray/VLESS should be hidden behind fallbacks / SNI- or path-based routing.
• For incorrect handshakes or unexpected SNI, return real web content, not an empty or obviously non-web response.

This reduces detection risk and avoids failures caused by strict behavior when the handshake is manipulated.

⸻

3) Provide alternative transports that currently survive better than “raw TLS” (important)

Please provide at least two alternative profiles so users can switch if needed, for example:
• VLESS + WebSocket over TLS (WSS), and/or
• VLESS + gRPC over TLS, and/or
• VLESS + xHTTP (HTTP-based transport; often helps by changing traffic patterns).

(Optional) A CDN-based option is acceptable if you support it, but I understand the trade-offs.

⸻

4) Reduce “high-signal” settings and traffic anomalies (important)

Some current filtering appears more effective against configurations that generate unusual TLS patterns (e.g., many short-lived TLS sessions, certain flows). Recommendations:
• Do not use xtls-rprx-vision by default. If you keep it, provide it as a separate optional profile; the default should be without Vision.
• Consider using Mux/Multiplexing with reasonable concurrency to reduce the number of repeated TLS handshakes.

⸻

5) (Optional) TLS handshake fragmentation / mitigation for ClientHello interference

There are indications that the network equipment may tamper with or corrupt the initial TLS ClientHello, or otherwise degrade handshake reliability. If you support it, please provide a separate “anti-DPI” profile that uses appropriate fragmentation/noise options at the Xray layer (where applicable).

Expected outcome

Please:
1. apply the TLS and fallback hardening above,
2. provide at least two alternative profiles (e.g., WSS+TLS and gRPC+TLS / xHTTP),
3. confirm what exactly was changed (TLS/ALPN/SNI/fallbacks/mux/flow, etc.).

Thank you.