Sign in Get Started

Add Jetpack IPs to an Allowlist

Last updated:

Control who can (or cannot) access your website by allowing IP addresses in WordPress.

Make sure Jetpack can access your site so that we can run backups, security scans, and restore it back to a previous version.

Allow all communications between Jetpack and WordPress.com

If you want to ensure Jetpack can communicate with your site, or if you have been advised to allowlist our IPs by support, please allow these IP ranges:

Jetpack IPs

  • 122.248.245.244/32
  • 54.217.201.243/32
  • 54.232.116.4/32
  • 192.0.80.0/20
  • 192.0.96.0/20
  • 192.0.112.0/20
  • 195.234.108.0/22
  • 192.0.64.0/18

Important: These IP addresses are subject to change. If you are writing IP-based firewall rules, you’ll need to update those rules any time the addresses change. We also have machine-readable versions of these IP ranges in JSON and plain text format that you can use to automate configuration changes on your systems.

Jetpack and XMLRPC.php access

Jetpack uses xmlrpc.php to communicate with WordPress.com. If xmlrpc.php is blocked for everyone, your Jetpack connection will stop working.

You don’t need to block xmlrpc.php entirely to protect your site. Instead, allow requests to xmlrpc.php from the Jetpack IP ranges above and block requests from everywhere else. The section below explains how to tell genuine Jetpack traffic from traffic that only claims to be Jetpack, and how to set up that rule.

Telling genuine Jetpack traffic from fake Jetpack traffic

Because Jetpack runs on millions of sites, bots often send requests to xmlrpc.php with a user agent that says “Jetpack” or “WordPress.com” so the traffic looks legitimate. A user agent is text the sender chooses, so it doesn’t prove where a request came from. Security researchers have found sites where most requests claiming to be Jetpack came from outside Automattic’s network.

A genuine request from WordPress.com to your site has all of the following:

  • It comes from one of the IP ranges listed above. This is the only reliable check. The list is kept current at https://jetpack.com/ips-v4.txt and https://jetpack.com/ips-v4.json. WordPress.com connects to your site over IPv4 only, so there is no IPv6 list, and your site’s domain needs an A record for Jetpack to connect.
  • It includes for=jetpack in the query string, along with token, timestamp, nonce, body-hash and signature parameters. Jetpack verifies that signature before running anything. A request to a bare /xmlrpc.php with nothing after it is not from Jetpack, whatever its user agent says.

A fake request fails Jetpack’s signature check, but WordPress has already loaded by then, so each one still costs your server a full PHP request. To stop that cost, block fake requests at the web server before WordPress starts.

Allow xmlrpc.php from Jetpack only

The rules below allow xmlrpc.php from the Jetpack IP ranges and return a 403 to everyone else. If you use the WordPress mobile apps, a desktop publishing tool, or another service that connects over XML-RPC, add its IP addresses too.

Apache (.htaccess)

<Files "xmlrpc.php">
    Require ip 122.248.245.244 54.217.201.243 54.232.116.4 192.0.64.0/18 192.0.80.0/20 192.0.96.0/20 192.0.112.0/20 195.234.108.0/22
</Files>

nginx

A separate location block for xmlrpc.php replaces the site’s normal PHP handling for that file, so the block has to pass the request to PHP itself. Copy the fastcgi_pass line and any other fastcgi settings from your existing location ~ \.php$ block.

location = /xmlrpc.php {
    allow 122.248.245.244;
    allow 54.217.201.243;
    allow 54.232.116.4;
    allow 192.0.64.0/18;
    allow 192.0.80.0/20;
    allow 192.0.96.0/20;
    allow 192.0.112.0/20;
    allow 195.234.108.0/22;
    deny all;
    # Same PHP handling as the rest of the site. Match these lines to your existing PHP location block.
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

Cloudflare

If your site is behind Cloudflare or another proxy, your web server sees the proxy’s IP address, not the visitor’s, so the rules above won’t work unless your server is configured to restore the real visitor IP. It’s simpler to add the rule in Cloudflare instead. Create a custom WAF rule that blocks requests where:

(http.request.uri.path contains "xmlrpc.php" and not ip.src in {122.248.245.244 54.217.201.243 54.232.116.4 192.0.64.0/18 192.0.80.0/20 192.0.96.0/20 192.0.112.0/20 195.234.108.0/22})

Don’t apply the allowlist to the whole site

Limit the rule to xmlrpc.php. Other Jetpack features reach your site from other networks. For example, Jetpack Boost generates critical CSS from the hosting providers listed in the Jetpack Boost section below, and the Jetpack image CDN fetches your images from its own servers. A site-wide IP allowlist would break those features.

Test after making the change

  1. Open Jetpack → Dashboard in your site’s admin and confirm the connection is still active. You can also check your site from the Jetpack debug tool.
  2. From a computer outside the Jetpack IP ranges, send a request to xmlrpc.php and confirm you get a 403:
curl -s -o /dev/null -w "%{http_code}\n" -X POST https://example.com/xmlrpc.php
  1. Check your access logs for //xmlrpc.php with a double slash. Some bots use it, and some log tools count it as a different URL. The nginx, Apache and Cloudflare rules above match it, but if you built your own rule, make sure it does too.

The IP ranges can change. If you build this rule by hand, check the published list from time to time, or script it from the plain-text or JSON list so it updates on its own.

Use Jetpack with Cloudflare (no additional security rules)

By default, Cloudflare and Jetpack should require no additional configuration to operate together if there are no additional security configurations specified with Cloudflare.

Use Jetpack with Cloudflare (additional security rules) and Sucuri

If you are using Cloudflare (with additional security rules) or Sucuri, please manually add Jetpack’s IPs.

If you are using Cloudflare they also support only allowing traffic coming from servers with a specific ASN (autonomous system number). To configure that, you can allow access to 2635.

  • 192.0.64.0/24
  • 192.0.65.0/24
  • 192.0.66.0/24
  • 192.0.67.0/24
  • 192.0.68.0/24
  • 192.0.69.0/24
  • 192.0.70.0/24
  • 192.0.71.0/24
  • 192.0.72.0/24
  • 192.0.73.0/24
  • 192.0.74.0/24
  • 192.0.75.0/24
  • 192.0.76.0/24
  • 192.0.77.0/24
  • 192.0.78.0/24
  • 192.0.79.0/24
  • 192.0.80.0/24
  • 192.0.81.0/24
  • 192.0.82.0/24
  • 192.0.83.0/24
  • 192.0.84.0/24
  • 192.0.85.0/24
  • 192.0.86.0/24
  • 192.0.87.0/24
  • 192.0.88.0/24
  • 192.0.89.0/24
  • 192.0.90.0/24
  • 192.0.91.0/24
  • 192.0.92.0/24
  • 192.0.93.0/24
  • 192.0.94.0/24
  • 192.0.95.0/24
  • 192.0.96.0/24
  • 192.0.97.0/24
  • 192.0.98.0/24
  • 192.0.99.0/24
  • 192.0.100.0/24
  • 192.0.101.0/24
  • 192.0.102.0/24
  • 192.0.103.0/24
  • 192.0.104.0/24
  • 192.0.105.0/24
  • 192.0.106.0/24
  • 192.0.107.0/24
  • 192.0.108.0/24
  • 192.0.109.0/24
  • 192.0.110.0/24
  • 192.0.111.0/24
  • 192.0.112.0/24
  • 192.0.113.0/24
  • 192.0.114.0/24
  • 192.0.115.0/24
  • 192.0.116.0/24
  • 192.0.117.0/24
  • 192.0.118.0/24
  • 192.0.119.0/24
  • 192.0.120.0/24
  • 192.0.121.0/24
  • 192.0.122.0/24
  • 192.0.123.0/24
  • 192.0.124.0/24
  • 192.0.125.0/24
  • 192.0.126.0/24
  • 192.0.127.0/24

Strict Firewall Configurations and Jetpack Boost

If you are using Jetpack Boost features alongside strict firewall rules, you will need to grant exceptions for Fly.io Hosting Provider Sub-processors. To take full advantage of all Jetpack Boost features, ensure the ASN for each of Fly.io’s Hosting Providers are added to an allowlist. At present those include CacheNetworks, Equinax, NetActuate, and OVH. If Fly.io adds new hosting providers, you can use PeeringDB.com to locate the ASNs to add to the allowlist.

Still need help?

Please contact support. We’re happy to advise.

Was this article helpful?