Using next-plausible to proxy POST requests to Plausible raises 405 Method Not Allowed error

Hi all,

I’m in the process of finishing off a Next.js site – – that uses the next-plausible plugin to integrate Plausible analytics. One of the features offered by the plugin is to proxy the analytics script and API calls so that they use local URLs, to avoid ad-blockers that target the public Plausible URLs.

Instead of including a script from, the proxy feature will expose a URL of which is proxied to the first, and instead of POSTing events to, is used.

Here’s my next.config.js file:

const withBundleAnalyzer = require('@next/bundle-analyzer')({
    enabled: process.env.ANALYZE === 'true',

const { withPlausibleProxy } = require('next-plausible');

module.exports = withPlausibleProxy()(
        webpack(config) {
            // ...
            return config;

So far, so good. The script URL is correctly proxied and the script is included. However when the script tries to POST an event to the proxied Plausible API endpoint ( which should be proxied to, it raises a 405: Method Not Allowed error.

I have used Postman to call the Plausible API directly and have verified as best I can that it’s Netlify that’s generating the 405 (there are Netlify headers in the response). A GET request to the proxy URL returns Plausible’s 404 page, which is expected behaviour. So it seems that the POST is being intercepted by Netlify rather than proxied to Plausible (but the GET works OK).

I’m using Netlify Forms (which I know also makes use of POST requests processed by Netlify) and this is working correctly – but I suspect this issue may be a result of how Netlify processes POST requests to handle form submissions.

I have been able to get next-plausible working by manually adding a rewrite to netlify.toml as follows:

  from = "/proxy/api/event"
  to = ""
  status = 202
  force = true

So my question is – is there any way around this or is it expected behaviour that any proxying of POST requests must take place in netlify.toml and cannot be done using rewrites in next.config.js (whether explicitly or via wrapper functions like next-plausible’s withPlausibleProxy?


As far as I’m aware, Next.js API routes on Netlify get converted to Netlify Functions. Not sure if my memory serves right on this, but chances are, they only support GET requests? We would confirm this with the devs in this week and let you know.

Hey @BigglesZX,

We heard back from the devs and this is their initial guess:

Our initial guess is the PlausibleProxy rewrite isn’t being captured correctly within the next.config.js and leading to an automatically generated rewrite within the netlify.toml that the runtime handles.

If the user explicitly were to define the rewrite within the next.config.js we think this would work similar to how it’s working when defined in the netlify.toml.

Could you potentially ask the user to confirm if explicitly writing a rewrite in the next.config.js file under the rewrites keyword works for you (without the withPlausibleProxy)?

Hi @hrishikesh,

Thanks for the quick follow-up – I did try adding the rewrites to next.config.js manually and the GET requests were correctly proxied but not the POST unfortunately. Only by manually adding it to netlify.toml was I able to get it working.

Hope that helps!

That’s interesting. Would you be able to provide a minimal reproduction so we could check what could be happening?

Sure – it might take me a few days though as I’m about to go on annual leave. I’ll get back to you :slight_smile:

Hi @hrishikesh,

I looked at this again today and with a minimal reproduction (a Next.js starter project + next-plausible + a configured Netlify form) the proxying of POST requests does work. So apparently something else in my project is causing this issue!

For the repro, I tried a plain Next.js project, then added and configured next-plausible, then added and tested a Netlify form, and all iterations worked OK. I then added a [[redirect]] configuration designed to block access to a particular subdirectory, as that exists in my main project, and the proxying still worked. So trying to make the minimal repro as similar to my main project as possible still failed to reproduce the issue.

Despite re-testing my main project in several different configurations I’m still getting 405: Method Not Allowed when POSTing to a redirected endpoint unless I manually configure the proxying in netlify.toml as originally described. So this must be being caused by something else in my project or some other quirk.

Would you be able to feed back to the developers and see if they have any other ideas?


Thanks for confirming… I’ll try asking them, but based on my discussion with them yesterday, we came to the conclusion of asking you to share a minimal repro because we were not sure what could be causing this. So, I am not super confident about anticipating a helpful response… :frowning:

@hrishikesh Sure, I understand – I guess the key question is under what other circumstances might Netlify intercept a POST request and return 405: Method Not Allowed, as the headers returned by that response do indicate that it’s coming from Netlify (i.e. not the proxied service). Thanks!

Hi, @BigglesZX. Looking at our logging, I do see the 405 statuses were being returned by the Next.js ISR code.

To understand why those 405s occurred we would need to debug that function itself. The ISR functions are running on AWS Lambda and we don’t have any secret or hidden way to debug those. If you want to debug one of these functions, adding console.log() function calls to the code in question to more verbosely log what the code is doing to reveal the root cause.

As far as which is better, I do believe that using the redirects feature of Netlify will perform better and be more reliable than proxying via an ISR function. The only time I would recommend using the function to proxy is if you need to programmatically modify the request or response. If you’re passing both through unchanged, the redirects feature is best.

If there are other questions about this, please let us know.

Thanks @luke, that’s much appreciated. I’ll try and do some more digging and see if I can figure out why ISR is being invoked in this case (as as far as I know the site isn’t using it) so I can write some general advice for next-plausible users.