u/vpn_fail

I’ve been building VPNFail MCP, and one of the more useful pieces is now working well enough that I wanted to share it with other scraping folks.

The basic idea is that a scrape can start as a normal HTTP request, but escalate to Chromium when the target actually needs JS rendering.

The browser request can also be pinned to a specific exit country or city.

So instead of maintaining separate proxy + browser infrastructure, an agent can do things like:

• fetch a page from a specific country
• request a particular city when location matters
• compare geo-dependent content
• inspect regional redirects
• check localized pricing/content
• render JS-heavy pages through Chromium
• optionally return a viewport screenshot

I deliberately kept the default path as plain HTTP because running a browser for every scrape is expensive and unnecessary.

The rough flow is:

HTTP scrape → inspect extraction quality → escalate to Chromium if needed → optionally choose geography

HTTP can return Markdown, text, or HTML. The response also includes quality metadata so the caller can decide whether the cheap extraction was good enough or whether it should retry using the browser.

The MCP exposes:

• scrape
• usage
• service_status

Example config:

{
  "mcpServers": {
    "vpnfail": {
      "type": "http",
      "url": "https://mcp.vpn.fail/mcp"
    }
  }
}

No local install and currently no account required.

https://mcp.vpn.fail/

I’m particularly curious how people here handle geo-aware scraping today.

Do you normally expose country/city directly to the scraping client, or keep geography hidden behind your proxy infrastructure?

Also interested in cases where city-level routing has actually mattered versus country-level being enough.

I’ve been building VPNFail MCP, and one of the more useful pieces is now working well enough that I wanted to share it with other scraping folks.

The basic idea is that a scrape can start as a normal HTTP request, but escalate to Chromium when the target actually needs JS rendering.

The browser request can also be pinned to a specific exit country or city.

So instead of maintaining separate proxy + browser infrastructure, an agent can do things like:

• fetch a page from a specific country
• request a particular city when location matters
• compare geo-dependent content
• inspect regional redirects
• check localized pricing/content
• render JS-heavy pages through Chromium
• optionally return a viewport screenshot

I deliberately kept the default path as plain HTTP because running a browser for every scrape is expensive and unnecessary.

The rough flow is:

HTTP scrape → inspect extraction quality → escalate to Chromium if needed → optionally choose geography

HTTP can return Markdown, text, or HTML. The response also includes quality metadata so the caller can decide whether the cheap extraction was good enough or whether it should retry using the browser.

The MCP exposes:

• scrape
• usage
• service_status

Example config:

{
  "mcpServers": {
    "vpnfail": {
      "type": "http",
      "url": "https://mcp.vpn.fail/mcp"
    }
  }
}

No local install and currently no account required.

https://mcp.vpn.fail/

I’m particularly curious how people here handle geo-aware scraping today.

Do you normally expose country/city directly to the scraping client, or keep geography hidden behind your proxy infrastructure?

Also interested in cases where city-level routing has actually mattered versus country-level being enough.

Seeing the usual “what still works?” threads plus a lot of VLESS/Reality / 3X-UI / router questions lately.

Curious what people would actually hand a normal friend (not a homelab person) in Aug 2026:

• commercial app / paid subscription
• self-hosted panel on a VPS
• travel/roaming SIM first, proxy second
• whole-home router box vs per-device clients

Constraints: they need something that still works after one provider gets burned, and they won’t debug Xray SNIs at 1am.

What would you put on a one-page cheat sheet for them? What’s the first thing that usually fails for newcomers?

Disclosure: I built and operate VPNFail MCP.

Quick update from the early public beta: scrape can stay on plain HTTP for most pages, then escalate to Chromium when the content is JS-rendered. You can also ask for a verified exit country/city, and optionally get a viewport screenshot.

What I tried to keep boring on purpose:

• Streamable HTTP endpoint — nothing to install locally
• Default path is cheap HTTP → Markdown / text / HTML
• Browser path is opt-in and rate-limited harder (~1/5 of the HTTP allowance)
• Tools: scrape, usage, service_status

Why this shape: most agent fetches do not need a full browser. Paying Chromium cost on every URL is how scrapers get expensive and flaky. The response includes quality metadata when the HTTP extract looks incomplete, so an agent can decide whether to retry with browser mode.

Basic client config:

{
  "mcpServers": {
    "vpnfail": {
      "type": "http",
      "url": "https://mcp.vpn.fail/mcp"
    }
  }
}

Project page: https://mcp.vpn.fail/

Still public beta / no account required. Especially looking for feedback on:

• MCP client compatibility (Cursor, Claude, custom agents)
• When agents should escalate to browser vs stay on HTTP
• Whether country/city selection is the right set of knobs
• Markdown quality on messy docs sites

Happy to answer implementation questions or take “this broke for my agent” reports.

Disclosure: I built and operate VPNFail MCP.

I wanted a simple way for MCP-compatible agents to fetch web pages through a rotating proxy pool without requiring users to create an account or manage API keys.

The public beta is now live, here's the project page and documentation:

https://mcp.vpn.fail/

Basic configuration:

{
  "mcpServers": {
    "vpnfail": {
      "type": "http",
      "url": "https://mcp.vpn.fail/mcp"
    }
  }
}

It currently exposes three tools:

• scrape — fetch an HTTP or HTTPS page as Markdown, plain text, or original HTML
• usage — inspect your anonymous rolling quota usage
• service_status — check proxy-exit availability and service health

Current free limits:

• 250 requests per hour
• 1,000 requests per day
• 5,000 requests per week
• 10,000 requests per 30 days
• Two concurrent requests
• No registration or API key required

The service selects a live proxy exit and retries through the pool when necessary. It uses Streamable HTTP, so there is nothing to install locally.

This is still an early public beta. Headless-browser rendering, JavaScript execution, location selection and sticky sessions are not available yet - they are roadmap ideas rather than current features.

I would especially appreciate feedback on:

• MCP client compatibility
• Markdown extraction quality
• Latency and reliability
• Missing parameters or tools
• Whether the free quotas are useful for real agent workflows

Try it on something difficult and let me know where it breaks.