Current public IP

What these results mean

Public IP: the network address used for this request

The public IP is the source address our API sees for this request. When you connect to YiYiVPN, the lookup will usually show the selected route’s IP if your browser traffic goes through it. Note the result before connecting, then select a route and check again. If it hasn’t changed, make sure your client’s proxy is enabled and that your browser isn’t set to bypass it by a routing rule.

A change in public IP shows only that the route for this request changed. It doesn’t mean every app on your device uses the same route. Work software, streaming apps, and browsers may follow different network rules, so check them separately.

Country, region, and ISP: classifications from IP databases

Country and region come from an IP geolocation database; the ISP is the network provider returned by the API. These describe the public IP, not your device’s precise location. Database updates can lag, and the displayed location or provider may differ from the route name in your client. A name mismatch alone doesn’t mean the route is faulty.

Proxy detection: not a substitute for testing access

This page shows “Proxy detected” or “No proxy detected” only when the API explicitly returns a proxy status field. If that field is missing, it shows “Not provided by API” rather than treating missing data as a negative result. “No proxy detected” doesn’t prove your traffic is going direct, and detecting a proxy doesn’t guarantee that a particular platform will be accessible.

DNS Leak Check

DNS translates domain names into network addresses. Even if your browser’s web traffic goes through a proxy, its DNS requests may take a different route. A DNS leak occurs when a lookup leaves the expected path and is handled by an unintended DNS resolver.

1. Check your client’s DNS settings. See whether DNS interception or related DNS features are enabled. Setting names vary by client, so understand the current mode before changing anything. Don’t enable multiple conflicting DNS options just to get a particular result.
2. Check your browser’s Secure DNS settings. Browsers may have their own encrypted DNS settings. Compare these with your system and client’s DNS policies to see whether a separate resolver has been specified. Encrypted DNS isn’t inherently a leak; what matters is whether the DNS route matches your expectations.
3. Check the actual path of DNS requests. If your client provides connection details or local diagnostic logs, check for related DNS requests when opening the domain. Advanced users can also use system network diagnostics. The resolved address alone won’t tell you which resolver handled the request.
4. Clear the cache and check again. After changing settings, clear the DNS cache as instructed by your operating system and browser, then visit the target service. Compare the DNS route and access results before and after connecting so you don’t mistake a cached result for the effect of your new settings.

If you’re still unsure, note your client mode, operating system, and what you observed, then ask for help through the user dashboard support ticket. Before sharing diagnostics, redact subscription links, access credentials, and any unnecessary personal information. For a more complete troubleshooting process, see the beginner-to-advanced user guide.