ReqLock

ReqLock — also written RequestLock or Request Lock — is an outbound (egress) firewall for WordPress. It controls every call your site makes out to the internet, on both sides of the request: the server (PHP / WP HTTP API) and the browser (the HTML your pages render). One master switch puts your site fully in control of its own outbound traffic.

Modern WordPress sites are noisy: update checks, license pings, analytics, tag managers, external fonts, embedded widgets, AI APIs, and assorted “phone-home” calls all reach out to servers you don’t control. When those servers are slow, blocked, or down, your pages and your dashboard pay the price — and every one of them is a place your visitors’ data leaks out. ReqLock lets you shut that traffic off at will, instantly and reversibly, without editing theme files or hunting down plugins.

One switch, four jobs:

• Resilience — keep the site working when the external internet is cut or restricted (outages, regional shutdowns, upstream failures). Pages serve from local assets and wp-admin stops hanging on dead requests.
• Performance — slow or unreachable third-party calls fail instantly instead of stalling front-end and back-end page loads on long timeouts.
• Privacy — strip analytics, trackers, external fonts, and phone-home requests so nothing about your visitors leaves the server.
• Development — turn any install into a self-contained, offline-capable environment: no external calls, no tracking from a staging copy, no waiting on remote APIs while you work.

Use cases

• Outage / shutdown resilience. When upstream connectivity is throttled or blocked, a normal WordPress site stalls on every external call. Flip ReqLock on and the site keeps serving from local resources — admin included.
• Speeding up a sluggish site. A single slow analytics or font host can add seconds to every page load. ReqLock makes those calls fail fast instead of blocking the render.
• Privacy / no-tracking deployments. Run a site that provably makes no third-party requests — useful for privacy-first projects, internal tools, and compliance-sensitive setups.
• Local & staging development. Clone production to a laptop or staging box and ReqLock keeps it from phoning home: no analytics fired from a test copy, no license pings, no WordPress.org update checks slowing down wp-admin while you build. The site behaves the same with the network unplugged — ideal for offline coding, demos, and air-gapped boxes.
• Auditing what a site talks to. The Detected-hosts panel logs every external host the site reaches, so you can see exactly who your themes and plugins contact — then decide what to allow and what to cut.

What it blocks

Server-side (PHP / WP HTTP API)

• Outbound wp_remote_* requests to external hosts: WordPress.org update/version checks, analytics, AI APIs (OpenAI, Gemini), remote fonts, license/phone-home pings, etc. They fail instantly instead of timing out.

Browser-side (rendered HTML)

• External <script src> and external <link rel="stylesheet"> (e.g. Google Fonts)
• Resource hints: preconnect / dns-prefetch / preload / prefetch
• External <iframe> (replaced with a clean local placeholder)
• Inline analytics snippets: Google Analytics / Tag Manager, Microsoft Clarity, Ahrefs, Meta Pixel, Hotjar, Yandex, TikTok, Pinterest, LinkedIn, Twitter/X, Snap, Segment, Plausible
• Optional: external <img> (transparent placeholder)

Key behavior

• Your own domain and all its subdomains are always allowed.
• Allow-list for any other hosts that must stay reachable.
• Detected-hosts panel logs every external host seen, so you can build the allow-list fast.
• Per-category toggles — turn each blocking layer on/off independently.
• wp-config conflict control — detects a hard-coded WP_HTTP_BLOCK_EXTERNAL constant and lets you disarm it (comment it out) or re-arm it (restore it) in one click, so ReqLock is the single switch for external blocking. Edits are reversible, integrity-checked, and atomic.
• Inert when OFF — with the master switch off, the plugin does nothing, so it is safe to keep installed and flip on only when needed.
• Works over full-page caches — the output filter runs as the outermost buffer, so it covers cached page views too.

Credits

Developed and maintained by the Rackset DevOps Team — https://rackset.com