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. 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 sits upstream of the link split: endpoint fields, client core version, or clock sync rather than the network.
For the specific error strings themselves, including "Reality verification failed", "TLS handshake timeout", and DNS leaks, use the full errors reference linked below. This page stays 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.
