Tunnel Routing Frontend Errors Results in 404 on Cloudflare CDN

[BarneyGammond]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/nextjs

SDK Version

9.14.0

Framework Version

next 14.2.5

Link to Sentry event

No response

Reproduction Example/SDK Setup

Here is the Sentry build config:

withSentryConfig(nextConfig, {
  // For all available options, see:
  // https://www.npmjs.com/package/@sentry/webpack-plugin#options

  org: "XXX",
  project: "XXX",

  // Only print logs for uploading source maps in CI
  // silent: false,

  // For all available options, see:
  // https://docs.sentry.io/platforms/javascript/guides/nextjs/manual-setup/

  // Upload a larger set of source maps for prettier stack traces (increases build time)
  widenClientFileUpload: true,

  // Route browser requests to Sentry through a Next.js rewrite to circumvent ad-blockers.
  // This can increase your server load as well as your hosting bill.
  // Note: Check that the configured route will not match with your Next.js middleware, otherwise reporting of client-
  // side errors will fail.
  tunnelRoute: "/api/monitoring",

  // Automatically tree-shake Sentry logger statements to reduce bundle size
  disableLogger: false,

  // Enables automatic instrumentation of Vercel Cron Monitors. (Does not yet work with App Router route handlers.)
  // See the following for more information:
  // https://docs.sentry.io/product/crons/
  // https://vercel.com/docs/cron-jobs
  automaticVercelMonitors: true,
});

Here is the instrumentation Sentry config:

Sentry.init({
  dsn: "XXX",

  environment: process.env.NEXT_PUBLIC_ENVIRONMENT,

  // Define how likely traces are sampled. Adjust this value in production, or use tracesSampler for greater control.
  tracesSampleRate: 1,

  // Setting this option to true will print useful information to the console while you're setting up Sentry.
  debug: false,
});

Steps to Reproduce

1. Set up a frontend event handler to throw an error
2. On click, the frontend event handler would run inside a client component

function onErrorClick() {
    throw new Error('test')
  }

3. This was run on a development environment as well as a Staging environment with a Cloudflare CDN
4. The tunnelRoute option was then commented out in the Sentry build config and the change was deployed to staging
5. Step 1-3 were then repeated

Expected Result

1. I would expect an unhandled error to be recorded on Sentry for both environments sent via the /api/monitoring tunnel route
2. When the tunnelRoute config is removed I would expect the same behaviour except the error payload should be shown to go straight to Sentry in the networks tab

Actual Result

With Tunnel Route Config

The development environment sends the tunnel routed post request and received a 200 response:

Dev Response Body

{"id":"{valid event id}"}

The staging environment sends the tunnel routed post request and receives a 400 response:

Staging Response Body

{"detail":"bad sentry DSN public key","causes":["invalid project key"]}

The DSN's are not changed based on the environment and they are identical in the request payloads.

Without Tunnel Route Config

Both environments function as expected and are identical in their behaviour. The both send a POST request to a sentry.io address and errors are logged correctly in Sentry.

[s1gr1d]

Hello, how does your tunnel redirection endpoint look like on the server? Can you provide a small reproduction example?

[lforst]

Also relevant:

• Do you have middleware?
• What does your DSN look like?
• What do the requests look like in the browser dev tools?

[BarneyGammond]

Thanks for responding so fast!

We have Middleware in place but the matcher excludes /api paths:

The DSN is structured as follows:

https://{ 32 digit string }@o{ Organization ID }.ingest.us.sentry.io/{ Project ID }

Here are the Request Headers:

[s1gr1d]

Thanks for providing the additional information. Since the problem only occurs in the staging environment with Cloudflare it could be that the DSN is not properly forwarded in Cloudflare. You could check if there are any Web Application Firewall rules that might block of modify API requests, any Transform Rules or any other security settings that might strip certain headers.

And can you please also share your tunnel route endpoint?