VLESS Reality troubleshooting should start by separating verification failures, TLS timeouts, DNS leaks, IPv6 problems, and system proxy routing issues. For Iran-related traffic, compare Wi-Fi and mobile data, confirm client core version, check clock sync, and verify the exit IP before changing SNI or replacing the endpoint.

Test mobile data and Wi-Fi as two separate cases
On Iranian networks the same VLESS Reality endpoint often behaves differently on a carrier link than on a filtered home ISP. Mobile and fixed lines can handle IPv6, DNS, MTU, and blocked destinations in opposite ways, so a config that connects on one can stall on the other. Always keep two results: one on mobile data and one on Wi-Fi.
The comparison, not the error string alone, tells you what to fix.

Read the mobile-vs-Wi-Fi split
If mobile data connects but Wi-Fi does not, your endpoint fields and credentials are almost certainly fine and the home line is filtering or intercepting the path. Look at the ISP resolver, IPv6 behavior, MTU, and whether the destination is reachable at all from that line before you blame the config.
If both networks fail the same way, the problem is upstream of the link split, and that points back to endpoint fields, client core version, or clock sync rather than the network.
For deep dives on the specific error strings themselves, including "Reality verification failed", "TLS handshake timeout", and DNS leaks, follow the full errors reference linked below instead of re-diagnosing each code here. This page stays focused on the part that is genuinely Iran-specific: how the same setup splits between mobile data and Wi-Fi.

When to switch to a managed endpoint
If public or shared endpoints fail repeatedly, the problem may be churn rather than your client. A managed VLESS/Xray proxy gives you private credentials, stable support, and a known exit IP type. Proxy Poland provides VLESS/Xray alongside HTTP, SOCKS5, and OpenVPN on real mobile proxy infrastructure.
