# A U.S. IP Wasn’t Enough to Reach Help: Testing 15 Consumer-Reporting Services

**Original research by FreePolicyTools · 16 October 2026**

We tested the places people are directed to report fraud, identity theft and consumer problems. Across 120 browser journeys, the question was practical: could we read the official guidance and reach the first reporting screen or its mandatory gateway?

The clearest finding was a restriction in the route itself. Our paid US IPv4 proxy refused HTTP CONNECT tunnels to all 14 `.gov` entry hosts in the sample. A separate diagnostic repeated those requests and received `403 Forbidden` with `PROXY_TARGET_FORBIDDEN` every time, before our client started destination TLS. The same diagnostic approved tunnels to the publisher’s website, IPinfo, and the sample’s `.com` Florida portal. The Florida page then displayed a separate website-side 403 in the browser.

This was an endpoint/account case study. It does not establish that every Proxy-Seller product or account has the same rule. Nor does it show government websites rejecting those 14 proxy visits: the browser could not establish the destination HTTPS connections through that proxy.


## What we tested

The [FTC](https://www.ftc.gov/news-events/topics/identity-theft/report-identity-theft) and [USA.gov](https://www.usa.gov/report-crime) direct people to the reporting services included here. The purposive sample contains five federal reporting services—FTC ReportFraud, FTC IdentityTheft, FBI IC3, CFPB and FCC—and consumer-complaint entry pages for the ten most populous states in the 2020 Census. Two FTC services count as two tasks, not two independent agencies. [The Census population table](https://www2.census.gov/programs-surveys/decennial/2020/data/apportionment/apportionment-2020-table02.pdf) defines the state selection.

Each service was visited twice through four routes: the normal Kenyan connection, a US Proton exit in Boston, a different US Proton exit in New York, and the paid US IPv4 proxy. The second pass reversed the service order. Browser exit identities were checked at the start and end of every pass, and raw addresses were retained privately. Public exit identifiers use HMAC-SHA256 over the captured IP digest with an unpublished study key, preserving route comparisons without exposing plain IP hashes.

Every journey used a fresh Chromium context, the same browser build and viewport, JavaScript enabled and normal certificate validation. We stopped before personal data, incident selections, login, terms acceptance, CAPTCHA completion or submission. Main collection ran from 2026-10-16T11:26:19.998Z to 2026-10-16T11:55:53.938Z. Pilot data are excluded.

The normal Kenyan route is contextual. It is not a matched US residential control. Differences between it and US exits can reflect geography, routing, reputation, DNS or other factors. The two VPN exits hold the country and browser constant, but do not isolate a single cause.

## The results, with gates kept separate from forms

“Readable entry” means the chosen guidance/entry page was readable. “Form/questionnaire” means the initial reporting questions or empty form were visible. Neither means a complaint could be completed. Counts below are **visits**, with 30 per route; two visits to one service are not independent users.

| Route | Readable entry | Form or questionnaire visible | Other observed endpoints |
|---|---:|---:|---|
| Normal connection · Kenya | 20/30 | 10/30 | Reporting notice: 2, Acknowledgement gate: 2, Security challenge: 2, Explicit denial: 6, Guidance only: 2, Embedded form unverified: 2, Network error: 2, CAPTCHA gate: 2 |
| Proton VPN · Boston | 24/30 | 14/30 | Reporting notice: 2, Acknowledgement gate: 4, Security challenge: 2, Explicit denial: 2, Guidance only: 2, Embedded form unverified: 2, Network error: 2 |
| Proton VPN · New York | 24/30 | 14/30 | Reporting notice: 2, Acknowledgement gate: 2, Security challenge: 2, Explicit denial: 4, Guidance only: 2, Embedded form unverified: 2, CAPTCHA gate: 2 |
| Paid IPv4 proxy · US | 0/30 | 0/30 | Proxy restriction: 28, Explicit denial: 2 |

The service-level matrix preserves both visits, in pass order:

| Service | Normal Kenya | Proton Boston | Proton New York | Paid US IPv4 proxy |
|---|---|---|---|---|
| FTC ReportFraud | Questionnaire / Questionnaire | Questionnaire / Questionnaire | Questionnaire / Questionnaire | Proxy restriction / Proxy restriction |
| FTC IdentityTheft | Questionnaire / Questionnaire | Questionnaire / Questionnaire | Questionnaire / Questionnaire | Proxy restriction / Proxy restriction |
| FBI IC3 | Acknowledgement gate / Acknowledgement gate | Acknowledgement gate / Acknowledgement gate | Acknowledgement gate / Acknowledgement gate | Proxy restriction / Proxy restriction |
| CFPB | Reporting notice / Reporting notice | Reporting notice / Reporting notice | Reporting notice / Reporting notice | Proxy restriction / Proxy restriction |
| FCC | Security challenge / Security challenge | Security challenge / Security challenge | Security challenge / Security challenge | Proxy restriction / Proxy restriction |
| California | Form visible / Form visible | Form visible / Form visible | Form visible / Form visible | Proxy restriction / Proxy restriction |
| Texas | CAPTCHA gate / CAPTCHA gate | Network error / Network error | CAPTCHA gate / CAPTCHA gate | Proxy restriction / Proxy restriction |
| Florida | Explicit denial / Explicit denial | Explicit denial / Explicit denial | Explicit denial / Explicit denial | Explicit denial / Explicit denial |
| New York | Form visible / Form visible | Form visible / Form visible | Form visible / Form visible | Proxy restriction / Proxy restriction |
| Pennsylvania | Explicit denial / Explicit denial | Form visible / Form visible | Form visible / Form visible | Proxy restriction / Proxy restriction |
| Illinois | Guidance only / Guidance only | Guidance only / Guidance only | Guidance only / Guidance only | Proxy restriction / Proxy restriction |
| Ohio | Network error / Network error | Acknowledgement gate / Acknowledgement gate | Explicit denial / Explicit denial | Proxy restriction / Proxy restriction |
| Georgia | Form visible / Form visible | Form visible / Form visible | Form visible / Form visible | Proxy restriction / Proxy restriction |
| North Carolina | Embedded form unverified / Embedded form unverified | Embedded form unverified / Embedded form unverified | Embedded form unverified / Embedded form unverified | Proxy restriction / Proxy restriction |
| Michigan | Explicit denial / Explicit denial | Form visible / Form visible | Form visible / Form visible | Proxy restriction / Proxy restriction |

60 of 60 service–route pairs had the same classified endpoint on both visits. Repeat consistency describes this session; it is not evidence of a permanent restriction.

## One browser error can hide two very different mechanisms

A website denial occurs after a connection reaches a website or its security infrastructure. A proxy tunnel refusal occurs earlier in the client’s connection setup. Our diagnostic sent only an authenticated CONNECT request to each entry hostname; it did not start destination TLS or send a complaint.

The decisive response fields on the tested `.gov` attempts were:

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

There were 28 such refusals across 14 government hostnames and two diagnostic repeats. The six control attempts to hosts outside `.gov` received `200 Connection Established`. Tunnel approval alone does not prove the destination page loads—the Florida browser result illustrates that distinction.

[Proxy-Seller’s FAQ](https://proxy-seller.com/faq/) describes usage restrictions and a support/KYC process for access to some restricted resources or ports. We did not request an exception, change account permissions or attempt to bypass the observed restrictions. The diagnostic records what this account and endpoint returned, rather than inferring an unpublished provider-wide policy.

## Different exits produced different reporting journeys

Pennsylvania and Michigan displayed explicit denials on both normal Kenyan visits. Their empty reporting forms were visible on both visits through each US VPN exit. Geography and other route differences prevent a claim that VPN use itself caused the improvement.

Ohio reached an acknowledgement screen through the Boston exit, returned an explicit request rejection through the New York exit, and failed to load through the normal connection. Each pattern repeated twice. Texas failed browser DNS resolution through Boston but reached its CAPTCHA gate through New York and the normal connection. These are specific route outcomes, not a provider-wide score.

The FCC security-verification screen appeared on the normal route and both VPN exits. Florida displayed a 403 page across all four routes. Neither pattern establishes VPN-specific exclusion.

## Reporting access extends beyond the guidance page

A readable introduction did not always expose an empty form. IC3 displayed its terms boundary, Ohio’s reachable reporting route displayed an acknowledgement, CFPB displayed pre-reporting notices, and Texas’s reachable reporting route displayed a screen announcing a required CAPTCHA check. The operability of the widget and the form beyond it were not verified. Those are separate outcomes, not interchangeable failures.

The [FCC’s own filing guidance](https://consumercomplaints.fcc.gov/hc/en-us/articles/205082880-Filing-a-Complaint-Questions-and-Answers) explains that users proceed from a complaint category to questions and contact information. A check of the entry URL alone cannot establish whether that journey is available. Our FCC observations stopped at a security-verification page, and we did not solve it.

North Carolina’s reporting wrapper was readable on the tested US VPN routes, but its embedded form did not expose readable fields within the fixed observation window. We classify the fixed-window main result as unverified. Longer headed checks made the questionnaire’s text available inside the SAS frame on the normal connection and both original VPN exits, but full-page screenshots still showed a blank form area. A further normal-connection viewport check reached a robot challenge, which we left unsolved. Visible form access remains unverified. These observations do not establish a deliberate block or an unavailable service. Illinois’s selected page offered guidance and printable resources; the frozen journey did not identify an online start control. Both limitations remain in the dataset.

## What this study establishes—and what remains open

The original contribution is a dated, reproducible set of reporting journeys with evidence distinguishing proxy restrictions, website challenges, reporting gates and actual form visibility. VPN accessibility itself has been studied before: a [2021 TU Delft thesis](https://repository.tudelft.nl/record/uuid:190ac398-50a0-4a47-9ec4-5514d5b22e25) found that looking beyond homepages changed the observed picture. Our study applies that concern to a small set of specific consumer-help tasks; it is not a claim to be the first VPN-blocking study.

The study uses one headless Chromium build, one normal connection, two VPN exit addresses and one paid proxy endpoint during one session. Proton’s existing malware-only NetShield setting remained enabled, which can affect DNS and is an additional route confound. Route blocks were run sequentially, so time is also a potential confound. The sample is purposive, and automated-browser treatment can differ from everyday browsing. DNS errors establish a failed lookup in the tested browser journey, not a site’s intention to exclude VPN users.

We did not test completion, agency responses, accessibility for assistive technologies, or the experience of actual victims. A CAPTCHA embedded on a readable form does not establish whether submission would succeed. Request-host metadata describes contacted infrastructure; it does not establish tracking, report-content transmission or improper handling. No report or personal incident data was entered or submitted.

## Evidence and reuse

Use the [interactive evidence report](report.html) to inspect the matrix and screenshots. Download [visit-level observations](observations.csv), [the protocol and amendments](protocol.md), [the frozen sample](sample-frozen.json), [CONNECT diagnostics](proxy-connect-diagnostic.json), and [source references](sources.json). Every published screenshot has a timestamp, route, pass and linked observation record. Both normal-connection Ohio visits failed screenshot capture; their navigation and screenshot errors remain in the observation records. Code and file hashes are included in the evidence bundle.

Readers citing these findings should identify the tested date, sample and routes, and link to the dataset alongside the article. A failed visit should not be repackaged as a universal claim about all VPNs, proxies or government services.

## Focused validation after the main run

Thirteen separate headed-browser checks followed the main experiment. In three longer NC checks, questionnaire text became available inside the SAS frame, but full-page screenshots remained blank in that area; visible embedded-form access therefore remains unverified. An additional normal-connection viewport check later reached a robot challenge, which was left unsolved. Ohio’s original Boston exit again reached its acknowledgement screen, while the original New York exit again returned a request rejection. Texas’s Boston DNS failure persisted with NetShield malware-only, off, then malware-only again at the same verified exit; its root cause remains undetermined. The headed proxy check again failed the FTC tunnel while the publisher HTTPS control loaded. Illinois still exposed guidance and printable resources in the selected journey. These exploratory checks do not replace the frozen main matrix.

## Affiliate and research funding disclosure

**Funding disclosure:** FreePolicyTools is a Proxy-Seller affiliate and received $10 in research credit. We reused one already purchased USA IPv4 endpoint. We made no additional purchase for this study. Proton VPN was supplied through the publisher’s existing subscription.