VLESS Reality Works on One Network but Not Another

When VLESS Reality works on one network but not another, the profile is not automatically broken. Keep the client, server, configuration, device, and test time as constant as possible, then compare access-network reachability, IP family, DNS, MTU, SNI handling, local policy, and path filtering one layer at a time. The first reproducible difference is more useful than cycling through random settings.

The complete VPN guide maps the whole connection. This guide assumes one known profile has already worked and focuses on a network A/B comparison, not general “VPN will not connect” troubleshooting.

Key Takeaways

• Capture a clean baseline on network A before changing anything on failing network B.
• Separate TCP reachability from REALITY authentication and later proxied traffic.
• Compare IPv4/IPv6, DNS answers, port policy, MTU symptoms, SNI handling, and route controls.
• Do not disable certificate checks, weaken identifiers, or evade an owner's network policy.
• Preserve timestamps and sanitized evidence so the client, server, and network owner can inspect the same event.

Freeze the variables first when VLESS Reality works on one network but not another

Use the same device, client build, profile, server address, port, serverName, public key, short ID, underlying transport, and test destination. Test the two networks within a short window so a server update, DNS rotation, or certificate change is less likely to become a hidden variable.

Exporting a full profile is unnecessary and risky. Record non-secret field names and fingerprints where the client supports them, but redact user IDs, private keys, subscription URLs, access tokens, and exact private infrastructure. Never post a connection URI to a forum.

Build this comparison sheet before troubleshooting:

Evidence	Working network A	Failing network B
Date/time and time zone	Exact value	Exact value
Access type and owner	Wi-Fi/cellular/Ethernet	Wi-Fi/cellular/Ethernet
Ordinary HTTPS works	Yes/no	Yes/no
Server host and port	Same, sanitized	Same, sanitized
DNS A/AAAA answers	Recorded	Recorded
TCP stage	Connected/timed out/refused	Connected/timed out/refused
REALITY stage	Success/error and time	Success/error and time
Small request after connect	Result	Result

Is VLESS Reality server reachability the same on both networks?

Step 1: prove ordinary access before testing the tunnel

On network B, disconnect the profile and open a normal HTTPS page you are authorized to access. Complete any captive portal through its legitimate page. Do not accept a certificate warning; a portal that intercepts TLS is not a valid baseline.

Record whether the device has working DNS, a default route, and stable signal. If ordinary access is broken, repair or report that access network first. A VLESS Reality error cannot identify a tunnel-specific cause while the underlying connection is unavailable.

Repeat the same small ordinary request on network A. The goal is not a speed contest. It is to prove both networks can carry normal traffic at the time of comparison.

Step 2: identify the first failing stage

A client message such as “connection failed” collapses several stages. Use supported logs or a diagnostics view to find the earliest point that differs:

1. DNS resolves the configured server hostname.
2. The device selects an IPv4 or IPv6 address.
3. TCP reaches the configured port.
4. REALITY checks the server name, public key, short ID, and handshake.
5. VLESS authenticates and establishes the proxy session.
6. The selected application traffic is routed through the session.
7. The remote exit reaches the test destination.

Project X documents VLESS as a stateless lightweight transport protocol and lists the client-side server and identity fields.［1］ REALITY has separate target, serverNames, key, and short-ID contracts.［2］ Keeping those stages distinct prevents a TCP block from being mislabeled as a VLESS authentication problem.

Step 3: compare the server port and TCP reachability

If network B never completes TCP while A does, check the exact destination address and port. Guest Wi-Fi, workplace networks, mobile carriers, and filtered hotspots can permit common web destinations while denying unknown endpoints or ports. A local firewall or security profile can produce the same symptom.

Use only a bounded reachability test to your own service endpoint. Do not port-scan the network or third-party systems. Record timeout versus immediate refusal: a timeout suggests silence or filtering somewhere on the path, while refusal usually means an endpoint or intermediate device actively rejected the connection. Neither result alone names the responsible organization.

If the profile can use a different operator-approved endpoint, compare it as a later single-variable test. Do not move the service to a deceptive port or bypass an explicit network prohibition.

Compare addressing, handshake, transfer, and policy behavior

Step 4: compare IPv4 and IPv6 selection

The same hostname can return A and AAAA records. Network A may reach the IPv4 address while network B prefers IPv6, or an IPv6-only access network may depend on DNS64/NAT64 behavior that does not apply to a literal IPv4 address. The IPv6-only troubleshooting guide explains that boundary in detail.

Record the actual address family selected by the client, not just whether the device shows an IPv6 address. Compare server DNS answers on both networks and check whether the configured value is a hostname or literal address. A literal IPv4 endpoint cannot be synthesized by DNS64 because no DNS lookup occurs.

Do not disable IPv6 globally as a “fix.” That changes the network rather than proving compatibility and can break ordinary access. Use client or operator diagnostics to verify that the server publishes and listens on the address families the service claims to support.

Step 5: compare DNS without replacing it blindly

If the server is configured by hostname, resolve it on both networks and record all A/AAAA answers with timestamps. Different answers can be legitimate due to geographic routing, split DNS, stale caches, or resolver policy. A failed result may also be a local resolver problem rather than deliberate blocking.

Next separate server-name resolution from destination-name resolution after the tunnel connects. If the REALITY session establishes but websites fail, the latter path is more relevant. If the server hostname never resolves, the handshake has not started.

Do not replace DNS merely to evade a managed-network policy. On a network you control, an approved resolver comparison can be one variable, but restore the original setting and document both results. The ISP blocking overview explains DNS blocking without making every lookup failure evidence of censorship.

Step 6: inspect serverName and TLS-facing behavior

REALITY accepts configured SNI values through serverNames, and those values are expected to fit the target's certificate behavior.［2］ The project guidance also treats target protocol support and route placement as compatibility inputs.［3］ A network middlebox may handle a given SNI differently, but a typo, stale profile, or target change can also explain the result.

Compare the exact non-secret serverName and client version on A and B. If the configuration is identical and only B fails after TCP connects, preserve the handshake error and timing. Do not swap in random popular domains; the target and accepted name are a coupled server configuration, not a client camouflage field.

If ordinary HTTPS to the named target is blocked on B, record that separately. It supports a path-policy hypothesis but does not prove the REALITY flow received identical treatment.

Step 7: test for an MTU or fragmentation symptom

MTU problems often appear after a connection seems to start. A tiny request works, but larger pages stall; uploads fail before downloads; or the tunnel repeatedly resets when certificates or responses grow. That is different from a TCP connection that never opens.

Use a small request and one moderately larger authorized transfer through the connected session. Record whether failure begins only above a size threshold and whether packet loss is present. Avoid flooding, exhaustive probing, or declaring one magic MTU value for every path.

If the client exposes a documented MTU setting, change it only within supported bounds and only after preserving the baseline. Restore it when the test does not improve the same reproducible request. A successful smaller setting points to a path-size issue; it does not identify which hop discarded packets.

Step 8: check local and network policy

Look for managed device profiles, endpoint security, parental controls, private-DNS enforcement, content filters, guest-network terms, and explicit bans on personal tunnels. A work laptop on home Wi-Fi can still be governed by device policy. A personal phone on corporate Wi-Fi can be governed by network policy.

Do not uninstall management, disable security software, or disguise traffic to bypass a rule. Ask the owner whether the endpoint and port are permitted. If you own the filter, compare its logs for the exact timestamp and destination, then create the narrowest documented allowance only if policy permits.

If the goal is a connection that works on both networks rather than a repaired profile, a managed client is the shorter path. Install AethoVPN, connect on each authorized network to the same location from the app, and if that location stalls on the stricter network, try another one the load indicator shows in green. Start the 3-day free trial for that side-by-side check. Those results describe the managed service on your two networks; when you want your own VLESS profile fixed, the REALITY handshake checks above remain the test, because AethoVPN's published setup names no protocol.

Step 9: distinguish path filtering from server failure

Retest network A after the failure on B without changing the profile. If A now fails too, the server, account, certificate-related configuration, or service state may have changed. If A still succeeds and B fails repeatedly at the same stage, the access path becomes the stronger variable.

Use a second authorized device on B only as a confirmation. If both fail at the same TCP stage, focus on the network path. If one succeeds, compare OS address-family choice, app version, local firewall, and VPN permissions. Do not merge the case into a broad device-difference investigation until the network constant is proven.

No single symptom proves intentional detection. Congestion, broken IPv6, resolver differences, port filtering, MTU loss, and policy can all produce network-specific failure. Use the smallest explanation supported by the evidence.

Step 10: package evidence for the right owner

For the service operator, provide sanitized client/server versions, timestamp, selected address family, TCP result, REALITY-stage error, VLESS-stage error if reached, and the one-variable tests. For the network owner, provide destination IP category and port, timestamp, and whether ordinary HTTPS worked; do not disclose credentials or ask for a policy bypass.

If you administer both ends, correlate the client timestamp with server accept, handshake, authentication, and outbound logs. Absence of a server-side TCP accept while A succeeds points earlier in the path. A server accept followed by an authentication error points back toward configuration or clock evidence.

The VPN connection test guide helps verify routing after a connection succeeds. It should not be used to infer why the pre-connection handshake failed.

Summary

• Freeze the profile, device, server, and time window before comparing networks.
• Identify the first differing stage: DNS, address family, TCP, REALITY, VLESS, routing, or destination.
• Treat port, IPv4/IPv6, DNS, MTU, SNI, policy, and filtering as separate hypotheses.
• Retest the working network after the failure to rule out server-side drift.
• Keep tests authorized, bounded, reversible, and free of secrets.

FAQ

Does working on mobile data prove Wi-Fi is blocking REALITY?

No. It proves a path-dependent difference. Wi-Fi DNS, IPv6, port policy, MTU, captive portal state, device profile, or filtering could each be responsible.

Should I change the REALITY serverName on the failing network?

No. The name must match the server's configured serverNames and target behavior. Random substitution creates a different, usually invalid configuration.

Can an IPv6-only network reach an IPv4-only server?

Sometimes through DNS64/NAT64 when a hostname is used, but not universally. A literal IPv4 address bypasses DNS synthesis and may fail.

Why does the connection start but larger pages stall?

That pattern can indicate MTU or packet-loss trouble after the handshake. Compare a small and moderate authorized request before adjusting a documented MTU setting.

Is a TCP timeout proof of censorship?

No. A timeout shows no usable response reached the client. Routing loss, firewall rules, endpoint failure, congestion, and intentional filtering can look alike.

Should I turn off antivirus or device management to test?

No. Use logs and approved temporary controls on devices you administer. Never remove organizational management or security protections to force a connection.

What evidence should I send to support?

Send sanitized versions, timestamps, network types, DNS/address-family results, first failing stage, exact errors, and bounded A/B outcomes. Never send a full profile, keys, tokens, or subscription URL.

Disclaimer: This guide is for authorized troubleshooting. It does not authorize bypassing network policy, scanning third-party systems, or weakening authentication and device protections.

Sources:

1. Project X, "VLESS": https://xtls.github.io/en/config/outbounds/vless.html
2. Project X, "REALITY": https://github.com/XTLS/Xray-docs-next/blob/main/docs/en/config/transports/reality.md
3. XTLS, "REALITY README": https://github.com/XTLS/REALITY/blob/main/README.en.md

Sources checked 9 September 2026.

---

Related Articles:

• Understand the complete VPN path
• VLESS Reality failure checklist
• Troubleshoot a general VPN connection failure
• Verify routing after a connection succeeds
• Diagnose an IPv6-only access network