Reverse Proxy Headers

When running Bugsink behind a reverse proxy, you need to configure the reverse proxy to forward requests to Bugsink. This guide will help you configure the right headers and settings for your reverse proxy; it does not cover the more general setup of a reverse proxy.

Our recommended reverse proxy is Nginx; if you want something that JustWorks™, that might be the best choice. However, if you’re using a different reverse proxy, you can still use this guide to configure it correctly.

We further assume that if you’re using a reverse proxy, you’re also using HTTPS. Because you should be using HTTPS, and if you’re going to the trouble of setting up a reverse proxy, you might as well use HTTPS.

The Headers

  • Host: set this header to the original host. (In Nginx, you can use $host.) Bugsink uses the Host header to determine the domain of the request. If you don’t set this header, Bugsink will complain that some other host (typically localhost, or the IP address of the server) is not in ALLOWED_HOSTS.

  • X-Forwarded-Proto: set this header to the original scheme. (In Nginx, you can use $scheme.) If you’re only serving HTTPS, you can also simply set this header to the string https. This directive corresponds to the setting "SECURE_PROXY_SSL_HEADER" in your bugsink_conf.py file. If you don’t set this header, Bugsink will not be able to determine whether the current request is secure or not. This can lead to problems with the CSRF protection, i.e. the message "(wrong scheme); fix your proxy's X-Forwarded-Proto".

  • X-Forwarded-For: set this header to the client’s IP address. (In Nginx, you can use $proxy_add_x_forwarded_for.) When Bugsink is behind a proxy, it needs this header to know the original IP address of the client. This information is passed in the X-Forwarded-For header, and picked up by Bugsink because of the bugsink_conf setting USE_X_FORWARDED_FOR.