#Sentry behind an Nginx reverse proxy

19 messages · Page 1 of 1 (latest)

ember harbor
#

I'm deploying Sentry behind an Nginx reverse proxy, and I’m using F5 to route based on URL path. Here's the flow:
client → https://app.example.com/apm-test → F5 path-based route → https://apm-proxy.internal.com (Nginx VM) → proxies to http://10.0.0.10:9000 (Sentry backend)
So Nginx receives /apm-test/ requests and proxies to the Sentry backend.
🧩 The challenge: Sentry seems to expect root (/) URLs. When routed via /apm-test/, the UI loads partially or breaks because static files and APIs still reference / instead of /apm-test/.
🔧 I tried an Nginx workaround using sub_filter to rewrite paths:
sub_filter 'href="/' 'href="/apm-test/';sub_filter 'src="/' 'src="/apm-test/';
But some parts of the frontend still fail, likely due to JS routing.
👉 Is there a recommended way to run Sentry under a path prefix like /apm-test/ instead of at the root (/)?
Any guidance would be appreciated. Thanks!

violet masonBOT
#

Hi @ember harbor. I'm happy to dig into this for you! I'll check my internal sources for answers to your question! :wave:

#

Based on the knowledge sources, Sentry does not support running under a path prefix like /apm-test/. This limitation is explicitly mentioned in several issues and documentation.

According to the Sentry development documentation, path-based deployments are no longer supported:

"The URL prefix in which Sentry is accessible... does not work for path (we supported this years ago, but it became too difficult to maintain). Sentry needs to be at the root of its own (sub)domain or IP address." Missing support for URL sub paths

This is confirmed by Sentry team members in multiple GitHub issues:

"You can't, Sentry needs its own domain and cannot live on a path." Deploy sentry with a non independent domain

"Echoing what was said above, you will need your own domain for this. Sentry cannot live on a path." Deploy sentry with a non independent domain

Your approach with sub_filter in Nginx is creative but, as you've discovered, it's not sufficient because of how Sentry's frontend JavaScript works. The redirects and static resource loading are designed with the assumption that Sentry is at the root of its domain.

The recommended solution would be to:

  1. Set up a dedicated subdomain for Sentry (e.g., apm.example.com instead of app.example.com/apm-test)
  2. Configure your F5 to route based on the hostname rather than the path
  3. Configure Nginx to proxy to Sentry at the root level

This approach aligns with Sentry's design requirements and will provide the most reliable experience.

I hope this helps clarify the situation!

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@ember harbor Our robots are still learning and improving, please let us know if this response was correct by reacting below.

ember harbor
ember harbor
#

Hi

violet masonBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

Yes, that's the correct approach for deploying Sentry behind a reverse proxy. Based on the knowledge sources, Sentry requires its own domain and cannot be deployed on a path.

Your proposed architecture:

client → <https://apm.example.com> (public domain mapped to F5) → apm.internal.com (Nginx) → Sentry web

This setup aligns with the recommended approach for productionalizing Sentry. The documentation specifically states:

"We strongly recommend using a dedicated load balancer in front of your Sentry setup bound to a dedicated domain or subdomain." Self-Hosted Sentry

When configuring this setup, make sure to:

  1. Update the system.url-prefix in your config.yml file to match your new URL (https://apm.example.com)
  2. Update the SSL/TLS section in sentry/sentry.conf.py to avoid CSRF-related errors
  3. Consider adding USE_X_FORWARDED_HOST = True to your sentry.conf.py file to ensure proper host handling

For your Nginx configuration, you'll need to properly forward headers. Several users in the knowledge sources mentioned issues with headers when using reverse proxies, particularly with X-Forwarded-Proto and Host headers.

This approach will give you a fully functional Sentry deployment with proper routing and avoid the issues you were experiencing with path-based routing.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@ember harbor Our robots are still learning and improving, please let us know if this response was correct by reacting below.

ember harbor
#

But which domaini need togive public url or internal url @violet mason

violet masonBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

Based on the knowledge sources, you should set the system.url-prefix in your config.yml file to your public URL - the one that users will access in their browsers.

According to the documentation and user experiences in the GitHub issues:

  1. The system.url-prefix should be set to your public-facing domain (https://apm.example.com in your case), not the internal URL:

    "Once you have setup a load balancer or reverse proxy to your Sentry instance, you should modify the system.url-prefix in the config.yml file to match your new URL and protocol." Self-Hosted Sentry

  2. For internal communication between Sentry components, you would use the system.internal-url-prefix setting, which should point to your internal service:

    system.url-prefix: "<https://apm.example.com">
system.internal-url-prefix: '<http://web:9000'>

Several users in the GitHub issues reported CSRF verification failures and other problems when the system.url-prefix didn't match the domain that users were accessing Sentry through. Setting it to your public URL ensures that cookies, CSRF tokens, and JavaScript resources all work correctly.

If you're using a reverse proxy with SSL termination, you should also update the SSL/TLS section in your sentry.conf.py file to avoid CSRF-related errors.

I hope this clarifies which domain to use for your configuration!

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@ember harbor Our robots are still learning and improving, please let us know if this response was correct by reacting below.

ember harbor
#

Public domain mapped to f5 that do domsin based routing to internal domain that internal domain mapped to nginx that nginx routes traffic to sentry web @violet mason

violet masonBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

Based on your architecture description, you have:

  1. Public domain (apm.example.com) → F5 (domain-based routing) → Internal domain (apm.internal.com) → Nginx → Sentry web

For this setup to work correctly with Sentry, you need to configure the system.url-prefix in your config.yml file to match your public-facing domain - the one that users will access in their browsers.

According to the documentation:

system.url-prefix: "<https://apm.example.com">
system.internal-url-prefix: '<http://web:9000'>

The system.url-prefix should be set to your public domain (apm.example.com), not the internal domain. This is critical because:

  1. Sentry uses this URL for generating links in emails, UI elements, and API responses
  2. It affects CSRF token validation and cookie settings
  3. It ensures proper redirection after authentication

As mentioned in several GitHub issues, users experienced CSRF verification failures when the system.url-prefix didn't match the domain through which users accessed Sentry:

"The fix is to open sentry/config.yml file and set system.url-prefix to match your public URL." CSRF Verification Failed

Additionally, if you're using SSL termination at your F5 or Nginx layer, make sure to update the SSL/TLS settings in your sentry.conf.py file:

SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True
USE_X_FORWARDED_HOST = True

This configuration ensures that Sentry properly handles the proxied requests and maintains secure connections throughout your architecture.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: