Marc Kranat

Same here with the pro version which has worked fine for over 5 years

Aslo seeing 409 errors just started in the last week

this from logs

IP Timestamp PROXYBLOCK Method Response URL Cache Referer User Agent
x.x.40.194 22/Mar/2021:21:16:45 NOT BLOCKED POST 409 /wp-comments-post.php?for=jetpack CACHES:- https://jetpack.wordpress.com/
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36
x.x.102.68 22/Mar/2021:19:38:24 NOT BLOCKED POST 409 /wp-comments-post.php?for=jetpack CACHES:- https://jetpack.wordpress.com/jetpack-comment/
Mozilla/5.0 (Linux; Android 9; SAMSUNG SM-G960U) AppleWebKit/537.36 (KHTML, like Gecko) SamsungBrowser/13.2 Chrome/83.0.4103.106 Mobile Safari/537.36

tried full re-install and re-config of jetpack (folder removed), for sure nothing with SSL cert, https forced.

No other errors.

Anything else I can try

No longer relevant, Parler is gone and I expect MeWe will follow

I’m not seeing that: https://tools.pingdom.com/?_ga=2.60383790.224522227.1528771185-2093959.1528771185#!/c6ZIlR/iServants.com

Does it clear when you clear the firewall cache?

It’s a crude fix, but you can block the jetmon/1.0 UA in the firewall, shouldn’t cause any issues as you say you don’t have JetPack installed, but that will stop the monitoring.

Be nice though to find whats happening here as we really thought this was fixed, if you open a support ticket for the firewall, I will happily work with you to resolve this, please ask in the ticket for it to be escalated to me.

replied in wrong place so deleted

• This reply was modified 6 years, 9 months ago by Marc Kranat.

Hi @evansline9,

Sorry, the only solution where disabling the monitoring initially did not work, or was not possible, which triggers the request that to can be cached, is to block the jetmon ua of the request using the firewall or something in the .htaccess.

Yes @jeremy, I have him in email so we can discuss specifics, at least we know what the trigger is now, but where’s the message coming from that’s populating the cache?

odd as they are head requests, there is no other data. immediately following that monitor visit, the site (well homepage) shows as just that one line on an empty page, not cached by the site itself, but in this case the Sucuri firewalls cache, I have seen cases of multiple hosts and CDNs also caching this. I tested with all plugins disabled, including JetPack, only comes after that monitor visit is recorded in logs,

# curl https://removed[.]com

Hi Jetpack! All systems go.

# curl -I https://removed[.]com
HTTP/1.1 200 jetpackok
Server: nginx
Date: Sun, 15 Oct 2017 02:38:13 GMT
Content-Length: 30
Connection: keep-alive
Age: 0
X-Cache: uncached
X-Cache-Hit: MISS
X-Backend: all_requests
Via: http/1.1 removed[.]prod.phx3.secureserver.net (ApacheTrafficServer/5.3.2 [c sSf ])
X-Sucuri-Cache: HIT
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-Sucuri-ID: 14008
Accept-Ranges: bytes

All odd as I can’t find that text in the plugins code, and this is just a head request, blocking your UA is not very elegant a fix, maybe you can find something better.

I confirm it works with the Sucuri WAF now, saves checking access logs, thank you.

I think it’s the JetPack update that broke it, not the WP one, there are a few more posts here with the same issue,

“Connection reset by peer” implies it’s something on the host dropping the request, try disabling any firewall plugins, if that doesnt work, maybe the corresponding error log on the host will tell you the cause.

@pctevree Seeing the exact same thing on only one out of a few blogs I manage, what I notice is this one is the only one running nginx.

The only 400 error, well really a 405 (when i check server logs) is the from the /wp-admin/admin.php?page=jetpack-debugger test on /xmlrpc.php, but that is expected as it is a GET, not a POST, which is what you normally see on that url, i am not sure this is even connected with the subscription emails not going out, as all other requests on /xmlrpc.php respond correctly with a 200.

@dominiquehurley are you also using nginx?

Hi codepeople,

If you want me to test an implementation I am happy todo so,

Thanks again,

If you or your hosting company are using a reverse proxy server of some sort, your security plug in what ever it is would be seeing all logins coming from the proxy’s IP address.

If that’s the case, and you can’t configure the WordPress or the plug-in to see the real users IP, put a captcha on the login, that will block the majority of brute force attacks which are whats triggering the lockouts.
If you can’t login to disable the security plug-in, just rename it via ftp.

Hi @zookatron

Just this:

/%year%/%monthnum%/%postname%

Been like this for a few years