WordPress (nginx-varnish) Jetpack xml_rpc 32700 glitch fix

My wordpress setup is hosted on a micro instance VPS on Amazon EC2 cloud running Ubuntu 12.10 64-bit, mysql, php-fpm, nginx web server and varnish cache http accelerator and after I install and try to activate jetpack I’ve experienced the following error:

Your Jetpack has a glitch. Something went wrong that’s never supposed to happen. Guess you’re just lucky: xml_rpc-32700. Try connecting again.

Error Details: The Jetpack server could not communicate with your site’s XML-RPC URL. Please check to make sure http://yoursite.com/xmlrpc.php is working properly. It should show ‘XML‑RPC server accepts POST requests only.’ on a line by itself when viewed in a browser and should not have any blank links or extra output anywhere.

The URL request that’s being made and fails is: http://yoursite.com/wp-admin/admin.php?page=jetpack&action=register&_wpnonce=********** where ********** represents an alphanumerical code cooked up by Jetpack (like: bf67aebc88)

As many others before me I’ve also run into the jetpack problem mentioned above, however it seemed that none of the solutions I’ve found out there fixed the issue for me, mostly due to the specifics of the server setup, therefore I’ll illustrate below how I’ve fixed the problem for myself, and I’ll also provide some links to additional resources that have worked for others (for users who are mostly having to do with shared hosting environments).

Additional note: this fix also works for the situation in which you’re trying to use the WordPress for Android mobile app and your’re trying to add your self hosted blog to the android app – which fails without the steps below. Just as in the case of the Jetpack fix, this only has to be done once, so you might consider activating Jetpack and adding your self hosted blog to the android app at the same time as to not have to repeat the steps below.

WordPress for Android error message: org.xmlrpc.android.XMLRPCException: org.xmlpull.v1.XmlPullParserException: unexpected type (position:END_DOCUMENT [email protected]:1 in java.io.InputStreamReader

Solution (nginx – varnish):

If you are unfamiliar with LEMP (Linux server using Varnish, Nginx, W3 Total Cache, and WordPress), have a look at this post to get started.
In the this setup combination the culprit is actually Varnish which seems that although is passing through the request to the nginx backend (a.k.a no cache), some of the .js scripts required by Jetpack are not loaded/executed but rather served from the Varnish cache, leaving the jetpack plugin with incomplete data while attempting the request.
To fix this we could go ahead and blow our brains out trying to tweak the varnish configuration .vcl file to properly handle the request, but given that this Jetpack activation is a one time thing we’ll just go ninja, do it faster and with very little downtime.

Step 1:

Open the nginx configuration file specific for your site:

edit and change the listening port to port 80. Typically nginx would be listening on a specific port (like 8080) for requests from varnish (which would be listening on 80).

save and exit the file:

Ctrl+x > y > Enter

Step 2:

Now that we’ve changes nginx listening port to 80, before we can reload the configuration for the changes to take effect, we must stop the Varnish webserver, and we do that by issuing the following command:

Step 3:

With the Varnish server stopped it is not time to reload the nginx configuration for the webserver and we do that by issuing the following command:

Step 4:

What’s happening now is that all wordpress requests are handled by nginx directly and are no longer passing through the Varnish caching layer.
Now go back in you wordpress blog, and click on the Jetpack tab > Connect to WordPress.com > Authorize Jetpack and voila…Jetpack has been authorized and enabled for your blog.

Note: as mentioned above, now would be a good time to also add your self hosted blog to the WordPress for Android mobile app to avoid having to redo these steps.

Step 5:

It is now time to undo what we did above with nginx and varnish in order to re-enable the varnish caching layer (don’t worry, only the activation had issue, everything else works well with varnish cache in front of it).

Open the nginx configuration file specific for your site:

Edit and change the listening port back to it’s original value (from 80 to 8080)

Save and exit the file:

Ctrl+x > y > Enter

Reload the nginx web server configuration for changes to take effect

Finally, it’s time to restart varnish cache:

Now it’s time to go back to your blog and play around with Jetpack as much as you want. You’ll find that pretty much everything works and you can enable and disable the various available modules, and you can even disconnect from WordPress.com if you want to, with no problem….however should you want the re-enable it, you’ll need to perform the above steps all over again.

Conclusion: the fix is rather simple actually, and if you read through the guide before actually doing it, it will take you less than a minute to complete, and with basically no downtime since you’re disabling varnish, but immediately enabling nginx as the fallback. This way, I think, is better than adding rules to the varnish configuration, since it’s something you only have to do it once, and just as the guide above it would still require you to stop and restart varnish.

Look at the common issues as depicted on the jetpack.me site: http://jetpack.me/troubleshooting/troubleshooting-tips/

Look at the plugin compatibility know issues on the jetpack.me site: http://jetpack.me/troubleshooting/known-issues/

Try the “XML-RPC De-whitespacer” http://wordpress.org/extend/plugins/xml-rpc-de-whitespacer/ plugin in order to remove any white spaces / empty lines from your themes and plugins.

If you’re running lighttpd instead of nginx/varnish, you should check out this post on how to fix jetpack connection issue.

Jetpack: Protection From Brute Force XML-RPC Attacks

You may have read the recent news report from Sucuri about the latest vulnerability to your WordPress XML-RPC file: Brute Force Amplification Attacks via WordPress XML-RPC

Brute force attacks against XML-RPC are one of the oldest and most common types of attacks to your site. Recently, according to Sucuri’s post above, attackers have found a way to “amplify” these attacks – making it easier for attackers to try and break into your site.

How can you protect yourself from these attacks?

Simple. Use Jetpack’s Protect module.

Sam Hotchkiss, one of our Jetpack developers, wrote an article today on his blog going over the more technical details on how this new attack method works and how Jetpack protects you from this new threat.

If you’re running Jetpack with Protect enabled, you don’t need to do anything to keep yourself safe from this. We’ve already got it taken care of for you!

Explore the benefits of Jetpack plans

Compare plans in detail to see how Jetpack can help you design, market, and secure your WordPress site.


Disable XML-RPC

This plugin disables XML-RPC API in WordPress 3.5+, which is enabled by default.

Remove XMLRPC Pingback Ping

Prevent your WordPress install from participating in pingback denial of service attacks.

Manage XML-RPC

Enable/Disable XML-RPC for all or based on IP list, also you can control pingback and…

Stop XML-RPC Attack

Block all access to your xmlrpc.php, except for JetPack and Automattic. Will poll ARIN for…

Eazy XMLRPC Pingback Disable

This plugin disables the WordPress XMLRPC pingback ping.


Make XML-RPC work if you rename the file. Some hosts block access to xmlrpc.php file…

Control XML-RPC publishing

Control remote publishing with XML-RPC from the writing settings page.

Prevent XMLRPC

Totally disables XMLRPC, preventing the recent Pingback spam vulnerability.

xmlrpc attacks blocker

multipie ways to help block xmlrpc attacks.

Syndicate Out

Syndicates posts made in any specified category to another WP blog using WordPress’ built in…

Deactivate XML-RPC on WordPress

This plugin will completely disable or deactivates XML-RPC on your WordPress installation. This will prevent…

Secure XML-RPC

More secure wrapper for the WordPress XML-RPC interface.

Disable XML RPC Fully

Simple plugin that disables XML-RPC.

WP Login Door

Did you ever feel like your website or blog login page is ridiculously fragile and…

Disable Pingbacks

This plugin disables the Pingback functionality in your blog.

Push Syndication

Syndication helps users manage posts across multiple sites. It’s useful when managing posts on different…

XO Security

XO Security is a plugin to enhance login related security.

XML-RPC Modernization

This plugin updates the WordPress XML-RPC API to leverage the latest features of WordPress and…

네이버 블로그와 워드프레스를 동기화 해주는 플러그인 입니다.

Disable XML-RPC & Unset X-Pingback

This plugin disables XML-RPC API in WordPress 3.5+, which is enabled by default.

Leave a Reply

Your email address will not be published. Required fields are marked *