PublicVPNList methodology

Responsibility and review history

Responsible team: PublicVPNList catalog maintainers. The team maintains the import, checker, publication and correction rules documented here; the listed VPN endpoints remain operated by independent third parties.

Methodology changelog: Aug 3, 2026 — clarified the shared snapshot fields, separated source-reported values from PublicVPNList checker measurements, and aligned country-page and sitemap indexability with current verified catalog rows. May 21, 2026 — documented stale-config handling and the report/takedown workflow.

The review date changes only when this methodology is materially edited. Snapshot and checker timestamps are operational data and do not change the methodology article's dateModified.

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.