Connected to Proton, Still “Unprotected”: What 6 VPN Websites Actually Checked

An original FreePolicyTools case study · Research conducted 14 October 2026 · One Debian PC, six provider websites, three connection conditions, 36 measured visits.

A VPN website can correctly display a VPN server's address and still show a warning that sounds as though the VPN is not working. Our measurements show why readers should examine the address and the scope of the test before treating a red label as a security diagnosis.

We compared six VPN-provider website surfaces on a normal Kenyan internet connection and two Proton VPN WireGuard connections, one exiting in Germany and one in California. We repeated the provider sequence in reverse order for each connection condition and saved the rendered pages, timestamps, screenshots, and independent route checks.

Across the two VPN-connected conditions, Surfshark retained its broad protection warning in all four planned visits. ExpressVPN retained its IP-exposure warning in all four, while its ISP field identified ProtonVPN. NordVPN showed a negative protection status in both usable VPN-connected visits; its other two attempts stopped at security challenges.

Other messages had a narrower scope. IVPN explicitly described whether the browser was connected to IVPN. Mullvad explicitly checked for Mullvad use. Proton's page continued to describe the address as visible to websites, including on visits displaying the VPN exit.

These observations do not establish a Proton leak, a defect in another provider's VPN, or deceptive intent. They establish that the wording on the sampled websites does not necessarily answer the question a visitor may have: is the VPN I am currently using carrying this connection?

Of 36 measured visits, 31 met our usable-result criteria. We retained two security challenges, two unresolved IP-field results, and one incomplete text capture as exclusions. This is a small descriptive case study, not an industry-wide ranking or a statistical estimate of how often VPN users encounter warnings.

Download the public dataset · Read the complete results · Read the collection protocol

During the Germany condition, ExpressVPN's IP checker displayed a German location and identified the ISP as ProtonVPN. In the adjacent card, it said: “Your IP address is currently exposed.” The California condition produced the same combination: a Los Angeles location, the ProtonVPN ISP label, and the warning. Both were reproduced in the reverse-order pass.

That juxtaposition is the strongest example in this dataset. The page was not merely showing an old home address alongside a generic warning. Its address matched the independently checked VPN exit, while the warning remained.

There are two different meanings of an address being visible. A destination must receive a source address for the connection it handles. With a working VPN, that address can be the VPN exit rather than the user's home address. Seeing an address on a checker therefore does not, by itself, demonstrate that the home address escaped the tunnel.

The relevant question is which address the page sees, not whether it can display any address at all. Proton's own IP-change instructions similarly advise comparing the public address before and after connecting. Our experiment preserved browser storage, so it did not reproduce the cookie-clearing step in those instructions.

Our sample contained four IP-check pages, a connection-check page, and a homepage connection-status header. The distinction matters: these interfaces have different purposes and should not be treated as identical security scanners.

Selection was purposive. We chose accessible primary provider pages relevant to connection checking, froze the six URLs, and retained all planned attempts. The sample is not a list of the six most-used VPNs, a random sample, or a recommendation to buy any provider.

We used one Debian 13 computer and the Codex in-app browser. The browser profile was shared across visits. Cookies and other site storage were not cleared, and no personal account was opened during collection. These observations describe a returning browser under the recorded conditions.

The native Proton desktop package was installed, but the research session did not expose native desktop controls. We therefore used existing Proton WireGuard profiles managed through NetworkManager. This article tests website messages, not Proton's desktop app, its connection display, or its kill switch. Proton documents the manual connection method in its Linux WireGuard guide.

Each provider had two planned visits per condition. The table reports the observed message category and whether the result was usable. It does not rank VPN security.

The two NordVPN challenges are important. We did not solve them, bypass them, or replace them with extra visits until a preferred result appeared. The successful reverse-order visits supplied the observed status for those VPN routes; the first-pass challenges remain separate records.

Similarly, Proton's visibility statement was readable in visits whose IP fields did not resolve correctly. We kept the statement as a qualitative observation but excluded those visits from claims requiring a verified displayed address. A page rendering text is not the same thing as its diagnostic component completing.

Surfshark's “Not Protected” label persisted in all four Germany/California observations. Its page also displayed a visible-address warning. The sampled addresses were the independently observed Proton IPv6 exits, rather than the IPv4 address seen on the native connection.

ExpressVPN's four VPN-connected observations likewise combined the exposure message with the expected Proton IPv4 exit. The ISP field identified ProtonVPN on both exits, in both passes.

These two cases support a precise conclusion: the sampled warning remained after the page's address information changed to the independently checked VPN exit. They do not establish the full algorithm behind either warning, how the pages would behave on those providers' own networks, or what a human reader would believe.

We did not hold Surfshark or ExpressVPN subscriptions, so their own-network positive controls were unavailable. That prevents us from concluding that the interfaces recognize only their own services. It also prevents any comparison of the products' actual tunnel protection.

For a visitor troubleshooting another VPN, the practical implication is still useful. A warning on a competing provider's page should prompt examination of the actual address and test scope, rather than an immediate conclusion that the current VPN failed.

In the usable Germany and California visits, NordVPN's header identified the ISP as ProtonVPN while displaying “Unprotected.” Both visits showed the expected Proton IPv4 exit. The native connection also received a negative protection status.

NordVPN's own support explanation says the website status means the visitor is not connected to its servers. That is directly relevant context, not a response obtained for this study. We did not contact the company.

Our observed Proton connection was not a NordVPN connection, so the documented brand-specific interpretation is consistent with the result. The communication issue is that the short visible status can sound broader than the explanation in the support article.

This is why we distinguish the wording a visitor sees from the documented scope of the test. It would be inaccurate to describe the observed NordVPN status as proof that Proton was not carrying the connection. It would also be inaccurate to claim we had discovered an undisclosed definition when the provider already explains it publicly.

IVPN's homepage described its status as “not connected to IVPN.” Mullvad's primary connection card said “Not using Mullvad VPN.” Both remained consistent across all six planned visits for their respective surfaces.

Those statements ask a specific question: is this connection using this named service? Our Proton connections were not IVPN or Mullvad connections, so a negative own-service result does not conflict with the network evidence.

The wording comparison is narrower than a provider ranking. We did not measure how people understood these labels, test their accessibility with participants, or audit every message elsewhere on the sites. A clearly scoped primary label also does not automatically make every secondary diagnostic label equally clear.

Mullvad provided an instructive example of that last point.

Mullvad's connection check displayed red secondary results during the Proton conditions. We examined the WebRTC panel on each VPN route rather than turning its red label into a leak allegation.

The Germany panel listed an IPv4 and an IPv6 address. Both matched the independently observed Proton exits for that route. The California panel did the same for its route. Neither expanded panel contained the baseline home IPv4 address.

The defensible finding is that the addresses listed in these two WebRTC panels were the checked VPN exits, not the recorded home address. That does not establish the absence of every possible WebRTC leak, private-address disclosure, or other browser-identification channel.

Mullvad's WebRTC guidance discusses interpreting its test when connected to Mullvad and checking the public address shown by a test. Its separate DNS-leak guide defines the problem in relation to using a non-Mullvad DNS server. Those provider-specific assumptions matter when another VPN is being evaluated.

We did not independently audit the DNS resolver results in this study. Some DNS panels were still checking at a saved checkpoint, while others showed a red result. The article therefore makes no finding that Proton leaked DNS, and no finding that its DNS configuration was leak-free. A proper DNS investigation would need separate resolver observations and a defined expected configuration.

Proton's page continued to say that the IP address was visible to the websites visited. Of four planned VPN-connected visits, three displayed an address matching the independent Proton IPv4 reference and met the usable-result criteria. The remaining California visit had unresolved diagnostic fields and was excluded from the matched-address conclusion.

On the usable visits, the visible address was the VPN exit. The general visibility statement therefore should not be reclassified as evidence that Proton exposed the home address. Our dataset records it separately from broad protection warnings and explicitly named service-connection checks.

This distinction is useful beyond this particular page. A message can be technically true about the visible network address while leaving unclear whether it is talking about the user's original address or a replacement exit. The surrounding instructions and the actual displayed value provide necessary context.

We did not ask one warning badge to validate another. We combined local routing evidence with external address observations.

Before and after the native block, we saved the active NetworkManager connection list, the IPv4 route to an external address, and public-address responses from ipify and Mullvad's JSON service. The two IPv4 responses agreed.

We then activated the existing Germany Proton WireGuard profile, verified that the route used its interface, and checked the external address responses. They agreed on the changed IPv4 address; Mullvad's response located it in Germany. We added ipify's universal endpoint during that block to obtain an independent IPv6 reference, because the browser displayed IPv6 on some provider pages.

We repeated the process for the California profile. Its independent response identified the country as the United States, while the provider pages that resolved location placed it in Los Angeles. We saved route checks at the end of both VPN blocks and after restoring the normal connection.

There are eight saved route-check records. Their paired IPv4 echoes agree within each record. These are records across connection states, not eight independent people or eight different VPN servers. The ipify documentation describes the public-address endpoints used; Mullvad has also documented its public JSON connection API.

For displayed-address comparisons, IPv4 was compared with IPv4 and IPv6 with IPv6. A website preferring IPv6 does not create a disagreement merely because an IPv4-only reference returns a different address. In the VPN observations with usable displayed address fields, those fields matched the relevant independently checked exit.

This verification establishes the sampled egress behavior and interface route. It is not packet-by-packet proof of whole-device protection, an independent cryptographic audit, or a test of the native app's kill switch.

Collection took place on 14 October 2026, from approximately 00:21 to 00:47 Africa/Nairobi. The JSON files use UTC timestamps, which fall on 13 October; these describe the same collection session.

We used the same six URLs for each condition. Pass one followed Surfshark, NordVPN, ExpressVPN, Proton, Mullvad, and IVPN. Pass two reversed that order. Connection blocks followed native Kenya, Germany, and California. Reversing provider order reduces a simple within-block order pattern, but it does not randomize the connection blocks or make the visits independent.

For each visit, the collector navigated to the target origin, enabled tab-level network instrumentation, disabled the HTTP cache where supported, and performed the measured reload. The minimum observation period ran from that reload's start. We preserved an initial DOM snapshot, a final rendered text extraction, a final DOM snapshot, and an original viewport screenshot.

Recorded elapsed times ranged from approximately 10.18 to 20.41 seconds and include capture overhead. They are not second-by-second measurements of a VPN transition. No consent choice was submitted during the measured visits. The shared browser's existing storage and consent state were retained.

Two design-stage visits were kept separately as exploratory material. They are outside the 36-visit denominator. A body-extraction timeout counted as an incomplete capture; a security-verification screen counted as a challenge. Readable page text with unresolved IP fields was not counted as a completed IP diagnostic.

The public dataset contains the connection condition, pass, actual timestamps, quality category, observed primary label, matched address families, and evidence filenames. Exact addresses, challenge URL tokens, account data, cookies, and incidental page prose are excluded. The original screenshots and text remain private research evidence.

Publication images are documented crops of those originals. We changed no warning text, colors, or status values. Cropping excludes IP fields rather than replacing a value with a fictitious one. The crop manifest records the source file and rectangle. Screenshots are evidence from this session, not permanent representations of the websites.

The most important limitations are concrete:

• One computer and one browser profile. Behavior can differ on other operating systems, browsers, devices, or clean profiles.
• One overnight session. We did not measure changes over days, website releases, or different times of day.
• One VPN provider and two exits. The results do not establish what happens with every VPN or every Proton server.
• No other providers' positive controls. We did not test Surfshark, ExpressVPN, NordVPN, Mullvad, or IVPN on their own paid networks.
• No native-app stress testing. We did not measure crash recovery, sleep/wake protection, tunnel failures, or the Proton desktop kill switch.
• Incomplete diagnostic components. Five planned visits were excluded under the stated quality rules; some secondary panels also remained unresolved at a checkpoint.
• No measurement of intent or consumer reaction. We cannot say why a provider selected its wording or how often users misunderstand it.
• No full privacy audit. Logging, malware protection, tracking resistance, DNS routing, and overall VPN quality require their own methods.

Existing public discussion already raises questions about VPN website warnings. We do not claim to be the first to notice the issue. This study's contribution is a dated, repeated comparison with preserved screenshots, address-family-aware verification, retained exclusions, and explicit distinctions between the different message types.

Start by recording the exact page, message, and time. Check whether the wording names a particular VPN service or makes a broader claim. If the provider offers an explanation of the label, read it before deciding what the result means.

Next, compare the actual public address before and after connecting using a reputable independent endpoint. Keep IPv4 and IPv6 separate. If the home address remains visible where you expect a VPN exit, that deserves investigation. If the page instead shows the expected VPN exit, a general warning alone does not demonstrate a home-IP leak.

For a DNS or WebRTC result, expand the details and identify the listed addresses or resolvers. Compare them with the expected configuration rather than relying exclusively on the red or green state. Do not publish your home address, account screen, or connection credentials when asking for help.

Finally, test the risk you actually care about. A stable public-IP check answers a narrower question than a kill-switch experiment. A connection indicator answers a different question from a malware scan. No single badge can replace a defined threat model and suitable measurements.

Use our VPN testing checklist to separate address, DNS, WebRTC and failure tests. Our reporting-service access research shows why a failed page journey needs its own diagnosis, and the HTTP-client routing study explains why a saved proxy setting is not proof of the route. Those proxy-client results do not establish the behavior of a VPN desktop app.

Our results suggest a practical wording improvement: label the question being answered.

These are editorial suggestions, not validated replacements from a user study. They would make the distinction between product recognition, IP visibility, and actual leakage easier to inspect.

Suggested citation: FreePolicyTools. “Connected to Proton, Still ‘Unprotected’: What Six VPN Websites Actually Checked.” Research collected 14 October 2026. Article URL: https://freepolicytools.com/blog/vpn-website-protection-warnings/.

The accompanying dataset, results, protocol, and source index allow inspection of the actual sample and exclusions. Private originals are retained for verification; they should not be uploaded without privacy review.

This article does not rank providers. Proton VPN affiliate offers are separate from the recorded findings; see the affiliate disclosure at the end. The researcher used an existing paid Proton subscription. No providers were contacted, and quoted support material is existing public documentation, not a company response to the study. No claim is made that any provider intended to mislead users or violated a law.

The supported finding is a gap between broad website warnings and the narrower questions that the saved connection evidence can answer. A useful diagnosis starts with the address, the test, and its scope.