v2ray.cnHome connections almost always get IPv6 now, while plenty of nodes only have an IPv4 exit. When the two sides disagree you get failures that look completely random: most sites are fine, a handful will not load; or the proxy is clearly running, yet an IP checker still shows your real address.
Symptom 1: only some sites fail
Your machine resolved an AAAA record, but the node has no IPv6 exit, so the connection just times out. Set domainStrategy to UseIPv4 on the freedom outbound to force IPv4 results only; that usually clears it immediately.
Symptom 2: the IP checker shows your real address
The classic dual-stack leak: IPv4 goes through the proxy while IPv6 leaves directly. Load something like test-ipv6.com and look at the IPv6 row — if it shows your local address, that stack was never captured. Check whether your routing rules skipped the IPv6 ranges; for the name resolution side see DNS leak protection.
Symptom 3: it only breaks in TUN mode
TUN captures traffic at the adapter level, and if the virtual adapter only carries IPv4 routes, IPv6 traffic walks around the tunnel and out the local interface. v2rayN's TUN settings include IPv6 options: either capture both stacks or disable IPv6 in the operating system. Do not leave it half-done.
Symptom 4: you cannot reach an IPv6-only server
The reverse case: the node is IPv6-only, but your network has no IPv6 or your ISP hands out a broken one. Nothing on the client can work around that — you need a different node or an IPv4 listener on the server.
The blunt but effective approach
While diagnosing, untick IPv6 in the network adapter properties to reduce the problem to one variable. Once you have confirmed IPv6 really is the cause, come back and configure it properly — leaving it off permanently breaks local services and internal network access that rely on it.