Can You Reach Help Through a VPN? We Tested 15 Reporting Services

A US IP address was not a passport to the reporting form. We tested the places people are directed to report scams, identity theft and consumer problems, and found several distinct boundaries between reading the guidance and reaching the reporting process.

The FTC directs consumers to its fraud and identity-theft portals. We followed those services and other official US reporting journeys through a normal Kenyan connection, two US Proton VPN exits and one paid US IPv4 proxy. Each of the 15 services was visited twice, using the same browser build and fresh contexts.

The clearest mechanism appeared before destination HTTPS began: the tested proxy refused tunnels to all 14 .gov entry hosts. Other outcomes included readable forms, reporting notices, acknowledgement boundaries, security checks, explicit denials and DNS errors. Those outcomes are kept separate throughout this article.

The 195 images comprise 186 main screenshots and nine validation captures. Thirteen headed-browser checks and 34 CONNECT requests are separate from the 120 main journeys. Two normal-connection Ohio screenshot captures failed and remain recorded as unavailable.

What the experiment found

The paid proxy returned PROXY_TARGET_FORBIDDEN for every tested government entry hostname. A separate two-repeat diagnostic confirmed 28 tunnel refusals across the 14 .gov hosts, before our client started destination TLS. The publisher website, IPinfo and Florida’s official .com portal received tunnel approval in all six corresponding control attempts.

That distinction matters. Florida is an official government service hosted outside .gov, not a non-government website. Its tunnel opened, but the browser then received a website-side 403. We therefore have evidence for two different mechanisms: a proxy-side refusal and a later website-side denial.

For the VPN routes, Pennsylvania and Michigan exposed forms through both US exits while the normal Kenyan route showed explicit denials. Ohio behaved differently between the two US exits. These are specific route observations; the Kenyan route is not a matched US residential control. Our VPN versus proxy guide explains why the two tools also differ in how they carry traffic.

All 15 services, with both visits preserved

Each cell shows pass 1 and pass 2. A form or first questionnaire means the initial reporting interface was visible. A notice or mandatory gate does not establish access beyond it, and no outcome establishes that a complaint could be submitted.

All 60 of 60 service–route pairs had the same classified endpoint on both main visits. That describes the measured session, not a permanent restriction. Scroll the table horizontally on smaller screens.

Reading a page and reaching a form are different results

The normal route exposed readable entry pages in 20 of 30 visits and a form or questionnaire in 10. Both VPN routes exposed readable entries in 24 of 30 visits and forms or questionnaires in 14. The proxy exposed neither a readable entry nor a form in these journeys. Those are visit counts from this small, purposive sample—not estimates for all sites or users.

A proxy 403 is a different event from a website 403

For HTTPS over an HTTP proxy, the browser first asks the proxy to open a tunnel to the destination hostname and port. A refusal at that step prevents the client from establishing the destination HTTPS connection. A website denial, by contrast, occurs after traffic reaches the website or its security infrastructure.

CONNECT reportfraud.ftc.gov:443 HTTP/1.1

HTTP/1.1 403 Forbidden
X-Proxy-Error-Code: 0x38
X-Proxy-Error-Message: PROXY_TARGET_FORBIDDEN

The diagnostic sent authenticated CONNECT requests and stopped before destination TLS. It did not send a complaint to an agency. All 28 government-host attempts were refused. All six control attempts to the three other hostnames received 200 Connection Established. Approval alone does not prove a destination page loads, as Florida’s later 403 demonstrates.

Proxy-Seller’s FAQ describes usage restrictions and a support/KYC process for some restricted resources or ports. We did not request an exception, change account permissions or try to bypass the observed restrictions. This case study records what the existing endpoint returned.

Transport and authentication are separate questions. Our HTTP versus SOCKS explanation and original proxy encryption experiment examine those boundaries; neither protocol label guarantees that a reporting destination will be reachable.

A page-level warning is a different kind of evidence: our VPN website-warning investigation compares those messages with verified exits. Our client routing experiment separately tests whether applications honor proxy settings. Read the guide to VPN limitations before treating either reachability or a changed IP address as a general privacy guarantee.

The two US VPN exits did not produce identical journeys

Ohio reached its acknowledgement screen through Boston and returned an explicit request rejection through New York. The normal Kenyan connection failed to load it. Each pattern repeated twice in the main run. Headed-browser checks later reproduced the Boston acknowledgement and New York rejection at the original verified exit identities.

Texas failed browser DNS resolution through Boston, but the normal route and New York reached a screen announcing a required CAPTCHA check. The separate Boston check used malware-only NetShield, off, then malware-only again, with fresh browser processes and the same verified exit. The DNS failure persisted. That experiment did not identify its root cause.

Michigan and Pennsylvania showed explicit denials on the normal route and empty reporting forms through both US VPN exits. Geography, routing and other differences prevent a claim that VPN use itself caused that improvement. Conversely, the FCC security-verification page appeared on the normal route and both VPN exits, so it is not evidence of VPN-specific exclusion.

When investigating a similar problem, change one setting at a time and distinguish a failed DNS lookup from an HTTP denial. Our VPN troubleshooting guide explains the diagnostic sequence. A timeout by itself tells us little about a website’s intention.

Guidance, forms and mandatory gateways

The FCC’s filing guidance describes a journey from a complaint category to questions and contact information. Testing only the homepage cannot establish whether that process is available.

How we ran the research

The sample combines five federal reporting services—FTC ReportFraud, FTC IdentityTheft, FBI IC3, CFPB and FCC—with consumer-complaint entry pages for the ten most populous states in the 2020 Census population table: California, Texas, Florida, New York, Pennsylvania, Illinois, Ohio, Georgia, North Carolina and Michigan. State selection was fixed before outcomes. The two FTC services are separate tasks, not independent agencies.

For a practical companion, use our VPN testing checklist. Before interpreting a site error, verify which connection the browser actually uses and keep the browser and task consistent between observations.

What the 13 extra checks established

The supplementary checks used headed Chromium and are excluded from the fixed-window main matrix. The original US exit identities matched in these checks. For North Carolina, headed mode, normal scrolling and a 20-second additional wait changed together, so we cannot isolate the effect of any one change.

Questionnaire text became available inside the SAS frame in the first three longer NC checks, but the full-page screenshots still showed a blank form area. A further normal-connection viewport check reached a robot challenge. It was left unsolved. Visible form access therefore remains unverified; neither the blank capture nor the extracted text is a sufficient substitute for a visibly usable form.

The headed proxy check again failed the FTC tunnel while the publisher HTTPS control loaded through the same endpoint. The original VPN state was restored to disconnected and NetShield to malware-only after validation.

The screenshot evidence

These are real browser captures, losslessly converted to WebP. The original PNG captures remain in the local working study. The public conversion ledger maps original PNG hashes and dimensions to the WebP files. Previews show the top of each capture; open the full image to inspect it and follow the linked observation record for the exact context.

Images load in small batches only when the gallery is opened. The conversion ledger and file hashes allow integrity checks. Account pages, raw exit-check captures and credentials are excluded.

What this study can establish

The original contribution is a dated set of reporting journeys that distinguishes proxy restrictions, website challenges, mandatory gateways and visible forms. VPN accessibility has been studied before: a 2021 TU Delft thesis found that looking beyond homepages changed the observed picture. We apply that concern to a small set of consumer-help tasks, without claiming to be the first VPN-blocking study.

• Specific connections: one ordinary Kenyan connection, two US VPN exits and one paid proxy endpoint cannot represent all users, products or providers.
• No matched US residential control: geography, route reputation, DNS, sequential timing and automated-browser treatment remain possible explanations for differences.
• One session: repeat consistency within the main run does not establish persistence. Later validation is shown separately, including the NC challenge.
• Partial reporting journey: no report completion, agency response, accessibility testing with assistive technology or real victim experience was measured.
• Infrastructure metadata: request hostnames describe contacted infrastructure. They do not establish tracking, transmission of report contents or improper processing. No personal incident data was entered.

These limits are part of the finding. A failed lookup is a transport failure, a proxy refusal is a routing boundary, and an acknowledgement is a legitimate reporting step. Combining them into one universal “VPN blocked” number would hide the differences the study measured.

Download the data and methods

The public package contains the complete 120-record main dataset, 34 CONNECT diagnostics, 13 validation records, 195 WebP captures, exact sample, protocol amendments, source references and analysis code. Python 3 standard-library code reproduces the classification counts. Public image references and hashes have been updated for the WebP conversion; observation text and main results are preserved.

If you cite the study, identify the tested date, sample and routes, and link to this article alongside the dataset. The results should not be repackaged as a universal claim about VPNs, proxies or government services.

Frequently asked questions

The questions below distinguish what the measurements showed from what the experiment did not test.