PublicVPNList methodology

This page explains how the catalog turns public OpenVPN profiles and the new multiprotocol snapshot model into visible rows, what the checks measure, what they do not prove, and how server owners or users can request corrections. PublicVPNList is a catalog and measurement layer; it does not operate the listed VPN exit servers.

982visible server rows
167checked within 1 hour
982checked within 24 hours
21countries +0added last hour 4985.0 Mbpsfastest recent median
LiveUpdated 2 min ago

How we import profiles

The importer reads public OpenVPN sources such as direct .ovpn files, public profile bundles, CSV-style feeds and public repositories. A source must be reachable without account registration or captcha, and profiles must contain practical connection data such as a remote host, port and protocol.

Imported profiles are normalized into a common dataset with country, host, IP address, port, protocol, source name and timestamps where available. Import alone does not guarantee public display: a profile still needs enough useful data and current measurements before it appears in user-facing tables.

Multiprotocol transition

The production catalog is still OpenVPN-first, while the parallel multiprotocol snapshot adds explicit fields for service category, tunnel protocol, transport protocol, config format and authentication type. This lets the site distinguish VPN tunnels from public proxies instead of flattening every row into one generic server type.

Config publication is policy-gated. VPN Gate can publish compatible OpenVPN configs under the current source policy; VPNBook stays disabled unless permission is confirmed; public proxy feeds stay separate from VPN endpoints and are not presented as private VPN tunnels.

How we test reachability

Availability checks focus on whether an endpoint still looks usable from the monitoring environment. The checker evaluates recent response signals, protocol and port data, and whether the row has enough current information to be useful in the public catalog.

VPN and proxy checks are run by external checker workers on isolated owner-controlled machines. The web host stores results and builds snapshots; it does not launch untrusted VPN configs as part of page rendering or API reads.

A successful check means the server passed the technical visibility rules at that time. It does not guarantee that the server will stay online, accept every client, or work from every user network.

How we measure speed

Speed is stored as measured Mbps from the latest available check window. The catalog uses this number as a practical quality signal, not as a permanent capacity claim. Public VPN endpoints can be overloaded, rate-limited or routed differently depending on the user's network.

Rows with no useful speed measurement are kept out of the main indexable catalog. When choosing a server, compare speed together with latency, checked time, country, protocol and port.

How we detect stale configs

Configs can become stale when the remote host disappears, the port changes, the profile is removed from the source, the endpoint stops responding, or repeated checks no longer produce useful measurements. Stale or broken profiles can be hidden from country pages, downloads and sitemap entries.

The public dataset favors rows that are current enough to help users make a decision. Older imported profiles may still be useful for rechecking or deduplication, but they should not be treated as live recommendations.

How we handle removal requests

Server owners, network operators, source maintainers and users can request removal or correction through Contacts. Include the host or IP address, port, protocol, country label, source URL if known, and the requested action.

For ownership or operator requests, include enough context to verify that the request is legitimate. Credible reports may lead to correction, exclusion from public pages, or removal from future import queues.

What we do not verify

PublicVPNList does not verify the legal identity, logging policy, internal security controls, ownership, jurisdiction, employee access, malware filtering, content manipulation or long-term trustworthiness of third-party VPN operators.

The checks also do not prove that the country label is legally exact. IP geolocation and source hints can be imperfect, so country should be treated as a practical routing signal rather than proof of physical location.

Public VPN safety limitations

OpenVPN encryption protects the connection between your device and the VPN endpoint, but the endpoint operator can still control the exit path. Unknown public VPN servers may log metadata, change DNS behavior, throttle traffic, inject rules, disappear suddenly or publish stale profiles.

Use public VPN profiles for low-risk testing, route comparison, troubleshooting and OpenVPN client setup practice. Avoid banking, work systems, private accounts, identity documents, medical portals, source code and other sensitive traffic unless you trust the operator.

Frequently asked questions

Does this methodology make public VPN servers safe?
No. It explains technical catalog checks. It does not verify the operator or make unknown public endpoints trustworthy for sensitive traffic.
Why can a server disappear from a country page?
A row can disappear when it stops passing visibility checks, loses useful measurements, becomes stale, duplicates another row or is removed after a credible report.
Can I ask for a correction or takedown?
Yes. Send the host or IP, port, protocol, source URL if available, and the requested action through the contact page.

Methodology and safety