Skip to content
IP Location Block
Home Pricing Articles Docs Changelog Contact My Account Get Started

Using IP Location Block with Jetpack

Updated Aug 24, 2026

Shared guide

Jetpack links your site to WordPress.com, and part of that link is inbound requests from Automattic servers. Location rules that cover XML-RPC or the admin area can block those requests, so the connection fails even though the plugin is doing exactly what you configured.

Connect before you tighten rules

The simplest order is to connect Jetpack while admin-side protection is off, then turn on your rules and add the allowances below. Connecting later works too, but the allowances have to be in place first.

The XML-RPC conflict

Jetpack reaches your site through xmlrpc.php from Automattic addresses, which are not in the countries your visitors come from. When XML-RPC is validated by location, those requests are blocked and either the connection handshake or individual features stop working.

XML-RPC is covered by Also protect wp-admin & login in the Simple view, and by the XML-RPC control in Back-end target settings, which has three values.

  • Disable: XML-RPC is not validated by location.
  • Block by location: your country rule applies. Add the allowances below.
  • Completely close: XML-RPC is refused for every caller.

Completely close leaves Jetpack no route in. Do not choose it on a site that uses Jetpack, the WordPress mobile app, or another remote publishing client.

Allow the Jetpack address range

Add Jetpack’s published range under Advanced > Validation rules and behavior > Proxy and IP overrides > Whitelist of extra IPs (CIDR, ASN).

192.0.64.0/18

That list is evaluated before the country rule and applies to every validated target, so a request from the range passes whatever your country list says. Automattic can change its ranges, so confirm the current one in Jetpack’s own documentation before you rely on it.

Allow the Jetpack admin actions

If admin, Ajax, or post requests are validated, Jetpack’s own admin screens can be blocked for an administrator who is travelling. Open Back-end target settings > Exceptions > Admin ajax/post exceptions. The plugin keeps a curated list of known request names, so Jetpack entries such as jetpack, jetpack_modules, and authorize are already offered in the picker and you do not have to type them. Nothing is excepted until you select it and save.

The same editor can list candidates found in your blocked logs, which is the quickest way to catch a request this page does not name. Keep each exception as narrow as possible.

Verify the connection

  1. Reconnect Jetpack from its dashboard.
  2. Open Validation logs and look for xmlrpc entries. A blocked row shows the address and country that were evaluated.
  3. Look that address up on the Search tab to confirm what your provider returns for it.
  4. Run Diagnostics again and read the recent blocked requests section.

Jetpack Protect and login blocking

Jetpack Protect blocks brute force login attempts using data collected across WordPress.com sites. IP Location Block stops requests to wp-login.php earlier, by location. The two do not compete: location rules remove traffic from countries you do not serve, and Jetpack Protect still handles attempts from the countries you allow. Keep both.