Troubleshooting
If OpenVPN says connected but websites do not load, the most common causes are stale public endpoints, broken DNS, missing default route, blocked port, or a profile that connected but did not push usable network settings.
Use this checklist after a public .ovpn profile connects but browsing, apps or package managers cannot reach the internet.
Choose a recently checked row before changing your whole device configuration.
Confirm whether the browser path moved through the tunnel.
DNS or default-route problems are the usual reason pages do not load.
Try TCP 443 or remove a stale imported public profile.
First disconnect and check the same website on the ordinary connection. If it also fails without the VPN, resolve that baseline problem first. If a guest network requires a sign-in page, complete its normal sign-in flow before reconnecting.
If browsing works but your public IP is unchanged, inspect split tunneling and route selection with the unchanged-IP checklist. For a profile intended to carry all traffic, also compare IPv4 and IPv6 results in the leak test; one successful request does not prove every traffic family uses the tunnel.
If names fail to resolve, compare the resolver reported by your operating system before and after connection. On Linux, resolvectl status shows resolver state where systemd-resolved is used; on Windows, ipconfig /all shows adapter DNS settings. These are inspection steps. A browser using its own DNS resolver can behave differently from other applications.
If DNS resolves but HTTPS requests time out, inspect the client log and routes. On Linux, ip route shows IPv4 routes; on Windows, route print lists routing entries. Test another freshly checked endpoint to distinguish one failing public server from a repeatable client or network issue. Do not disable certificate verification to make a test pass.
If small requests work but larger transfers repeatedly stall, use the MTU diagnostic and compare its observations with your client documentation before changing tunnel settings. Avoid changing DNS, routes and MTU at the same time: test one hypothesis, record the outcome, then undo an unsuccessful change.
The VPN client can show connected while browsers time out, apps stay offline, DNS names fail, or only some IP addresses respond. Record the exact symptom before changing settings.
Public endpoints disappear quickly. Download a fresh checked row, preferably one with low latency and a recent successful check, before assuming your OpenVPN client is broken.
Open the IP check before and after connecting. If the IP does not change, the default route may not be using the tunnel or the connection may have failed silently.
If IP traffic works but websites do not resolve, run the DNS leak test and inspect pushed DNS options in the .ovpn file. Public profiles may not provide reliable DNS.
On Linux use ip route; on Windows inspect adapter and route state; on Android reconnect after disabling aggressive battery limits. Missing default route means traffic can stay outside the tunnel.
If UDP times out on hotel, airport or corporate Wi-Fi, try a fresh TCP 443 profile. If TCP connects but feels unstable, compare a UDP row on a network that allows UDP.
Remove old public profiles from the client so you do not reconnect to an endpoint that no longer matches the live catalog.
Restart OpenVPN Connect, disable and re-enable the VPN adapter if routes are stuck, and remove old imported profiles after testing.
Open the profile from Android Files, allow VPN permission only for the intended app, and exclude the VPN client from strict battery optimization while testing.
Compare NetworkManager logs with terminal OpenVPN logs, then inspect ip route and resolvectl status.
Stop when multiple fresh profiles fail the same way on the same network; the network may be blocking VPN traffic or captive portal flow.
Use the IP check, DNS leak test, TCP 443 list, public VPN risks page and OS setup guides as the next diagnostic step.