HTTPS Requests being silently dropped?

tl;dr: CF is silently blocking incoming webhook/ipn requests (e.g. from paypal) - they never appear in logs, rules are correctly configured, endpoints reachable manually, payloads are not malformed. I'm looking for answers as to why this is happening now (after many years of it working fine).
inb4 "cloudflare doesn't silently block requests" - yeah, they do. please, read on.

I've been using cloudflare for about 5 or so years as my DNS provider and to proxy the connections to my webserver. It's always been pretty great and the features I used always worked more or less as I expected them to.
A few months ago though, suddenly, without any changes on my end, paypal was no longer able to reach my backend ipn script. I already had a rule for the url to prevent it being blocked which had been working fine for years.
I could still reach the script myself, and using cloudflares own trace tool, I could confirm that the script could be reached (matching the rule), even when closely matching the payload, user-agent etc. from paypal.
The weirdest part: cloudflare wasn't logging anything at all for the failed paypal connections. It was as though paypal were never sending the ipn payload - but they were - I confirmed it by changing the destination to a non-cloudflare host.
I spent a long time trying to diagnose the cloudflare issue but couldn't get to the bottom of it, so I churned from paypal and wrote a new implementation for a new payment provider. Everything worked, and I moved on with my life. (Note: this was with a 'Pro' account)

Recently a friend asked me to configure his webserver, cloudflare, etc. along with a payment system intergration - a webhook for mercadopago.
After getting everything set up and configured, having confirmed the webhook script on another non-cloudflare host, I deployed it on his backend, and lo and behold, cloudflare isn't letting the webhook through from mercadopago.
No log, nothing. Again, I confirmed the route, etc. All accessible. Everything fine. Except cloudflare isn't letting it through, somewhere upstream of this account. A fresh cloudflare account (free).
What the hell!
So this time I added a subdomain that wasn't proxied by cloudflare, gave it its own SSL (letsencrypt), re-wrote the webhook script as a standalone with its own database conn, and deployed it to the subdomain.
It works. The webhook arrives. Obviously I won't keep it like this because I am currently exposing the backend IP, i'll end up needing to put it elsewhere if I can't prevent cloudflare from blocking the requests upstream of my account.

So, to the question, what the hell is going on? Why are requests being silently blocked by cloudflare, and what can I do about it? What changed?!

Though I don't think any of this is actually relevant to the question, here are a few extra details:

apache2 web server on ubuntu24.04
cloudflare in full (strict) mode
cloudflare origin certs on the web server

Trying to find other people experiencing this in the wild:
https://community.cloudflare.com/t/cloudflare-is-blocking-lemon-squeezy-webhook/807437/13
https://community.cloudflare.com/t/site-inaccessible-to-discord-crawler-silent-block-by-cloudflare-proxy/813140/7
https://community.cloudflare.com/t/suspected-network-block-for-live-paypal-ipns-all-local-cf-config-ruled-out/814435/3 (this guy solved it by changing his minimum TLS from 1.3 to 1.2 - but that doesn't seem to be my issue)
https://community.cloudflare.com/t/apex-push-notifications-blocked-websocket-handshake-failing-at-cloudflare-edge/825642

Frustrating to see in every one of these posts of people looking for help, there is some guy stating emphatically that cloudflare doesn't silently block requests.

Idle•10/9/25, 7:26 AM

inb4 "cloudflare doesn't silently block requests"

they don't, check your WAF logs (most likely bfm though)

Idle•10/9/25, 7:26 AM

?skip-bfm

SuperHelpflare•10/9/25, 7:26 AM

Bot Fight Mode cannot be skipped by WAF Rules or other "Bypass" actions.
Bot Fight Mode is a very aggressive solution that should only be enabled if you are actively under attack.

Remedies:

Upgrade to a Paid plan and use Super Bot Fight Mode
Disable Bot Fight Mode

IIdle > inb4 "cloudflare doesn't silently block requests" they don't, check your WAF l...

MichaelOP•10/9/25, 7:27 AM

In my case, and in the case of the other people who have posted about such things, the requests are not in the WAF logs.
I can see requests that I personally initiate from home, and requests that I use Cloudflare Trace to initiate, but not from the external vendors.

Particularly strangely, on my original account, it was PayPal's IPN request that was being silently dropped. I re-wrote my cart system to use snipcart.js with their webhook, and that arrives fine.
On my friends account that I set up recently, PayPal's IPN is arriving fine, but MercadoPago's webhook request is being silently dropped.

Idle•10/9/25, 7:29 AM

general-helpPayPal-IPN Fails

Idle•10/9/25, 7:31 AM

seems to be a similar issue to yours, perhaps there's some relevant info there?

MMichael In my case, and in the case of the other people who have posted about such thing...

Laudian•10/9/25, 9:39 AM

The user in the other topic had the problem even when Cloudflare was disabled. Can you try to use a DNS-Only subdomain for Paypal and see if the requests arrive then?

LLaudian The user in the other topic had the problem even when Cloudflare was disabled. C...

MichaelOP•10/9/25, 9:41 AM

I've done this, and the requests arrive fine with that configuration (this is how I currently have it)

MMichael I've done this, and the requests arrive fine with that configuration (this is ho...

Laudian•10/9/25, 10:23 AM

What Cloudflare plan are you on? I'm asking so I know what type of logging you might have available.

LLaudian What Cloudflare plan are you on? I'm asking so I know what type of logging you m...

MichaelOP•10/9/25, 10:32 AM

Pro on the older account, unfortunately I can't use that one for testing now as I've fully migrated to a new provider and their webhook is working fine in prod as expected. Also outside of the log history for when it was occurring originally.

Free on the new account that I can currently replicate the issue on (a friends account that I have manage permissions to), If necessary, I'd take that account up to Pro

MichaelOP•10/9/25, 10:38 AM

For reference though, on the pro account where I could view the web traffic analytics, I was not getting any entry for paypal sending the IPN request (nor in the Security->Events logs)

Laudian•10/9/25, 10:40 AM

You sound like deploying a Worker would be relatively easy for you. Could you create a simple Worker that simply logs request headers + body to console so you can see live logs on your terminal?

MichaelOP•10/9/25, 10:41 AM

I could, this is essentially what I did on the non-proxied subdomain

Laudian•10/9/25, 10:41 AM

I'd share code but I'm only on my phone until later.

MichaelOP•10/9/25, 10:44 AM

Doing that allowed me to confirm that MercadoPago (the payment provider sending the webhook that is being silently dropped in this case) was in fact sending it.
I printed directly into the error log:

[Wed Oct 08 07:57:46.290169 2025] [php:notice] [pid 951183] [client 35.245.20.104:10086] \n--- REQUEST LOG ---\n{\n    "timestamp": "2025-10-08 07:57:46",\n    "ip": "35.245.20.104",\n    "method": "POST",\n    "query": "data.id=123456&type=payment",\n    "body": "{\\"action\\":\\"payment.updated\\",\\"api_version\\":\\"v1\\",\\"data\\":{\\"id\\":\\"123456\\"},\\"date_created\\":\\"2021-11-01T02:02:02Z\\",\\"id\\":\\"123456\\",\\"live_mode\\":false,\\"type\\":\\"payment\\",\\"user_id\\":378968694}"\n}\n

[Wed Oct 08 07:57:46.290169 2025] [php:notice] [pid 951183] [client 35.245.20.104:10086] \n--- REQUEST LOG ---\n{\n    "timestamp": "2025-10-08 07:57:46",\n    "ip": "35.245.20.104",\n    "method": "POST",\n    "query": "data.id=123456&type=payment",\n    "body": "{\\"action\\":\\"payment.updated\\",\\"api_version\\":\\"v1\\",\\"data\\":{\\"id\\":\\"123456\\"},\\"date_created\\":\\"2021-11-01T02:02:02Z\\",\\"id\\":\\"123456\\",\\"live_mode\\":false,\\"type\\":\\"payment\\",\\"user_id\\":378968694}"\n}\n

Laudian•10/9/25, 10:48 AM

that's the apache log?

MichaelOP•10/9/25, 10:49 AM

Yes, of the non-proxied subdomain, receiving the webhook successfully

Laudian•10/9/25, 10:50 AM

And when you set up a Worker and tail it, you don't even see the request?

MichaelOP•10/9/25, 10:53 AM

I'll do that specifically and report back - might take a little while as I'm relying on someone else to alter the webhook destination address

Update:

worker is up, and routed to the proxied domain
```
domain.com/worker
```
```
domain.com/worker
```
confirmed worker is working ()
waiting on the webhook url to be changed to this to see what (if anything) comes through

Update2:

heading to bed, no response from the guy who needs to change the endpoint address and force the webhook to be sent. Will update this when I can. Thanks for the advice so far.

Laudian•10/9/25, 11:16 AM

Please log both request as well as the response if you aren't already doing that.

MichaelOP•10/10/25, 1:06 AM

Alright, so the webhook URL got changed while I was sleeping.

I've just confirmed that MercadoPago sent a webhook to my worker route domain.com/worker
I was tailing at the time, and got nothing
Also had observability real-time events open - nothing
For reference, if I hit the target myself, or use Cloudflare Trace, I do get all of the logs

I'm going to take a poke around the analytics/logs/waf events etc. now, but I don't expect to find anything at all.

MichaelOP•10/10/25, 1:42 AM

For reference, when we simulate a webhook from mercadopago, we get this error (Unfortunately in Portuguese, but the error code is really all that matters here)
For completeness - this webhook arrives fine outside of CF proxy, and this attempt is not logged in any cloudflare logging that I can access

HTTPS Requests being silently dropped?

Similar Threads

Similar Threads

Similar Threads