Skip to content

Reverse Proxy Examples

Note: These examples assume you are using /ombi as your Base URL.
If your Base URL differs, replace all instances of /ombi with /YourBaseURL.
If you're using a subdomain (ombi.example.com), replace all instances of /ombi with /, and remove the first location block.

Why use a reverse proxy?

There are a few reasons to consider using a reverse proxy for providing access to Ombi.
These include:

  • Providing a nice URL for users to access (instead of "http://your.external.ip.address:port").
  • Providing a layer of SSL security for your Ombi users.

A "nice URL"?

By default, the internet uses IP addresses to communicate. A service called DNS provides a way to alias these addresses with nice names (www.example.com, for example), rather than the direct IP address. Think of it like a phonebook for the internet, allowing you to look up a more complicated entry with an easy to remember name.
Setting up a reverse proxy allows you to use a nice url like "your.site.com", instead of just your external IP address.

Providing SSL

Ombi doesn't do SSL in and of itself. We write a specific tool, for a specific purpose, and we're not going to be able to do SSL better than a dedicated web server software can.
As such, we recommend implementing a reverse proxy to handle that side of communication.

Nginx

To use nginx as a reverse proxy requires no extra modules, but it does require configuring.

This is an NGINX reverse proxy configuration that DOES use baseurl.
This has been tested both from a localhost redirect as well as through a router from a DMZ machine on Ubuntu 18.04.

The advantage of this configuration is that it allows for a single certificate to provide ssl services for many different web apps.

For example:
www.example.com/ombi
www.example.com/sonarr
www.example.com/radarr

You would only need to install/support a certificate for www.example.com.

This configuration is if you want to run a subdirectory configuration. Note, Ombi must be started with the --baseurl /ombi option (see here for startup parameters)

    location /ombi {
    proxy_pass http://<ip addr or hostname>:5000;
    include /etc/nginx/proxy.conf;
    }

    # This allows access to the actual api
    location /ombi/api {
    proxy_pass http://<ip addr or hostname>:5000;
    }
    # This allows access to the documentation for the api
    location /ombi/swagger {
        proxy_pass http://<ip addr or hostname>:5000;
    }
    client_max_body_size 10m;
    client_body_buffer_size 128k;

    # Timeout if the real server is dead
    proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;

    # Advanced Proxy Config
    send_timeout 5m;
    proxy_read_timeout 240;
    proxy_send_timeout 240;
    proxy_connect_timeout 240;

    # Basic Proxy Config
    proxy_set_header Host $host:$server_port;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Host $server_name;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_redirect  http://  $scheme://;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_cache_bypass $cookie_session;
    proxy_no_cache $cookie_session;
    proxy_buffers 32 4k;
    proxy_redirect http://<ip addr or hostname>:5000 https://$host;

If you wish to use ombi.example.com rather than example.com/ombi, then you need to create a site per service.
You will also need to ensure that ombi is not configured to use a BaseURL.
Each site has a separate config file in the sites-available directory. By default, this is /etc/nginx/sites-available.
We're going to use the site name as the file name, so in this case we need to put the following into
/etc/nginx/sites-available/ombi.example.com.conf
Note that this example does not enable SSL or generate a certificate, but that can be done afterwards using a tool like Certbot. Certbot will add the listen 443, generate, and apply the certificates using LetsEncrypt.
Of course, replace 127.0.0.1:5000 with whatever IP and port combination you are using for Ombi.
Ensure your Application Url (in Ombi) matches the server_name field.

    # Ombi v4 Subdomain
    # Replace EXAMPLE.COM with your domain
    server {
        listen 80;
        server_name ombi.*;
        return 301 https://$server_name$request_uri;
    }
    server {
        listen 443 ssl http2;
        server_name ombi.*;
        server_name ombi.EXAMPLE.COM;
        ssl_certificate /nginx/ssl/EXAMPLE.COM-chain.pem;
        ssl_certificate_key /nginx/ssl/EXAMPLE.COM-key.pem;
        ssl_session_cache builtin:1000;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers on;
        ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
        ssl_session_tickets off;
        ssl_ecdh_curve secp384r1;
        resolver 1.1.1.1 1.0.0.1 valid=300s;
        resolver_timeout 10s;
        gzip on;
        gzip_vary on;
        gzip_min_length 1000;
        gzip_proxied any;
        gzip_types text/plain text/css text/xml application/xml text/javascript application/x-javascript image/svg+xml;
        gzip_disable "MSIE [1-6]\.";

        location / {
            proxy_pass http://127.0.0.1:5000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        }
        # This allows access to the actual api
        location /api {
                proxy_pass http://127.0.0.1:5000;
        }
        # This allows access to the documentation for the api
        location /swagger {
                proxy_pass http://127.0.0.1:5000;
        }
    }

Once the config file(s) have been created (and saved), we need to enable the site. This is done by symlinking the config file into the sites-enabled directory. The below commands will achieve this (obviously, replace the ombi.example.com sections with whatever names you used for your setup).

ln -s /etc/nginx/sites-available/ombi.example.com.conf /etc/nginx/sites-enabled/ombi.example.com.conf

mklink C:\nginx\conf\sites-enabled\ombi.example.com.conf C:\nginx\conf\sites-available\ombi.example.com.conf

We then restart nginx to load the new config file, at which point your system will be listening on http://ombi.example.com for traffic.
(If you elect to set up certbot, it will change to https://ombi.example.com).

service nginx restart

nginx -s reload


Apache2

To run Apache with a reverse proxy setup, you'll need to activate certain modules. The following instructions are for Debian, please adjust commands for each package manager your OS uses.
(assume all commands require sudo):

    apt-get install -y libapache2-mod-proxy-html libxml2-dev
    a2enmod proxy
    a2enmod proxy_http
    a2enmod proxy_ajp
    a2enmod rewrite
    a2enmod deflate
    a2enmod headers
    a2enmod proxy_balancer
    a2enmod proxy_connect
    a2enmod proxy_html
    a2enmod proxy_wstunnel

In your Virtualhost configuration file you'll need to add a few things.
Note: VirtualHost configurations are usually under /etc/apache2/sites-enabled/

Just below the DocumentRoot entry:
ProxyPreserveHost On

You can then add the configuration for each item you wish to proxy.
There are two methods for doing this.
One is with a 'Location' section, the other is simply a direct mapping.
The mapping goes just before the </VirtualHost> closing tag, regardless of the method.
If you want to run ombi.example.com instead of site.example.com/ombi, then replace /ombi with / and drop the /ombi from the end of the internal addresses, as well as removing the BaseURL from Ombi itself.

    <Location /ombi>
    Allow from 0.0.0.0 
    ProxyPass "http://ip.of.ombi.host:5000/ombi" connectiontimeout=5 timeout=30 keepalive=on 
    ProxyPassReverse "http://ip.of.ombi.host:5000/ombi" 
    </Location>
    ServerName ombi.example.com
    <Location />
        ProxyPass http://ip.of.ombi.host:5000/
        ProxyPassReverse http://ip.of.ombi.host:5000/
        Order allow,deny
        Allow from all
    </Location>

Note: Lets Encrypt Support

Add ProxyPass "/.well-known/" "!" to the configuration file to allow Lets Encrypt to renew the subdomain TLS certificate.

Apache2 WebSocket requests

While WebSockets are not a requirement for Ombi to work, it does run a lot faster if it is able to use them. WebSocket requests need to be specifically handled when using a reverse proxy.
With Apache2, the configuration below needs to be applied in addition to any ProxyPass/ProxyReverse configuration in the <Location> or <VirtualHost> block. This will ensure WebSocket requests are handled correctly through the reverse proxy.

    RewriteEngine On
    RewriteCond %{HTTP:Upgrade} =websocket [NC]
    RewriteRule /ombi/(.*) ws://ip.of.ombi.host:5000/ombi/$1 [P,L]
RewriteEngine On
RewriteCond %{HTTP:Upgrade} =websocket [NC]
RewriteRule (.*) ws://ip.of.ombi.host:5000/$1 [P,L]

Once you have added this to the virtualhost config for your Ombi proxy (be it subdomain or subdirectory), you'll need to run service apache2 restart to make the changes go live.
For Linux distributions using systemd, you can use systemctl restart apache2.


IIS

NOTE: There are some extra steps involved with getting IIS to proxy things.
Install these two modules:

After installing the above, enable the proxy function via:
IIS admin -> Application Request Routing Cache -> Server Proxy Settings, tick "Enable proxy"

  • NOTE1: Below rules assume you have a "virtual directory" named "OMBI" under your default website in IIS.
    That VD should target a physical directory that resides at c:\inetpub\wwwroot\ombi.
    Within this directory you would place the below rules in a web.config file. There should be no other files in this directory.
    (This should NOT be your OMBI install directory)
  • NOTE2: Change example.com
<configuration>
    <system.webServer>
        <defaultDocument>
            <files>
            </files>
        </defaultDocument>
        <rewrite>
            <rules>
                <clear />
                <rule name="ReverseProxyInboundOMBI" stopProcessing="true">
                    <match url="(.*)" />
                    <action type="Rewrite" url="http://localhost:5000/ombi/{R:1}" />
                    <serverVariables>
                        <set name="host" value="$host" />
                        <set name="HTTP_X_FORWARDED_HOST" value="$server_name" />
                        <set name="HTTP_X_REAL_IP" value="$remote_addr" />
                        <set name="HTTP_X_FORWARDED_FOR" value="$proxy_add_x_forwarded_for" />
                        <set name="HTTP_X_FORWARDED_PROTO" value="$scheme" />
                        <set name="HTTP_X_FORWARDED_SSL" value="on" />
                    </serverVariables>
                    <conditions trackAllCaptures="true">
                    </conditions>
                </rule>
            </rules>
            <outboundRules>
                <clear />
                <rule name="Restore Encoding" preCondition="Restore HTTP_ACCEPT_ENCODING}" enabled="true">
                    <match serverVariable="HTTP_ACCEPT_ENCODING" pattern="^(.+)" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="true" />
                    <action type="Rewrite" value="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" />
                </rule>
                <rule name="ReverseProxyOutboundOMBI" preCondition="ResponseIsHtml1" enabled="true" stopProcessing="false">
                    <match filterByTags="A, Area, Base, Form, Frame, Head, IFrame, Img, Input, Link, Script" pattern="^http(s)?://localhost:5000/ombi/(.*)" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="true">
                        <add input="{HTTP_REFERER}" pattern="/ombi" />
                    </conditions>
                    <action type="Rewrite" value="http{R:1}://example.com/ombi/{R:2}" />
                </rule>
        <preConditions>
            <preCondition name="ResponseIsHtml1">
                <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
            </preCondition>
            <preCondition name="Restore HTTP_ACCEPT_ENCODING}">
                <add input="{RESPONSE_CONTENT_TYPE}" pattern=".+" />
            </preCondition>
        </preConditions>
            </outboundRules>
        </rewrite>
        <security>
            <authentication>
            </authentication>
        </security>
        <urlCompression doStaticCompression="true" doDynamicCompression="false" />
    </system.webServer>
</configuration>
  • NOTE 1: Below rules assume you have a dedicated site to run Ombi under in IIS.
    The address for this needs to match your application URL in Ombi, and should target a physical directory that resides at c:\inetpub\ombi.
    Within this directory you would place the below rules in a web.config file. There should be no other files in this directory.
    (This should NOT be your OMBI install directory)

  • NOTE 2: Change "ombi_ip:port" to whatever your local address for Ombi is.

  • NOTE 3: Be sure you set your application URL in Ombi to whatever your site in IIS is listening to.
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="HTTP to HTTPS redirect" stopProcessing="true" enabled="false">
                    <match url="(.*)" />
                    <conditions>
                        <add input="{HTTPS}" pattern="off" ignoreCase="true" />
                    </conditions>
                    <action type="Redirect" redirectType="Found" url="https://{HTTP_HOST}/{R:1}" />
                </rule>

                <rule name="RP_Ombi" enabled="true" stopProcessing="true">
                    <match url="(.*)" />
                    <action type="Rewrite" url="http://ombi_ip:port/{R:1}" />
                    <serverVariables>
                    </serverVariables>
                </rule>
            </rules>
            <outboundRules>
                <clear />
                <preConditions>
                    <preCondition name="Restore HTTP_ACCEPT_ENCODING}">
                        <add input="{RESPONSE_CONTENT_TYPE}" pattern=".+" />
                    </preCondition>
                </preConditions>
            </outboundRules>
        </rewrite>
    </system.webServer>
</configuration> 

Caddy

Caddy 2 is a powerful, enterprise-ready, open source web server with automatic HTTPS written in Go.
You can find Caddy here, and their docs can be found here.
An official docker image can be found here.
Otherwise you can direct install using a binary found here.

Note: The official binaries and Docker image do not include any of the DNS plugins required for wildcard certificates or DNS verification instead of port 80 verification. If your connection blocks port 80, you will need to build your own binary or image to include these.

domain.example.com {
    route /ombi* {
        reverse_proxy 127.0.0.1:5000
    }
}
ombi.example.com {
    reverse_proxy 127.0.0.1:5000
}

Traefik

Traefik is the a great reverse proxy option if you are using a container-based setup such as docker compose.
You can find Traefik here, and their getting started guide here.
For more information and examples on the usage of labels in docker compose (specific to traefik) go here.
Note: The following configuration examples only apply to traefik version 2 and later.
Note 2: All examples contain additional labels not necessarily required for your setup such as wildcard SSL certificates via Let's Encrypt and SSL related headers.

Adjust the values of traefik.docker.network=traefik_proxy, traefik.http.routers.ombi.entrypoints=https and traefik.http.routers.ombi.rule=Host(`ombi.example.com`) to match your specific setup.

The following configuration would make Ombi available at https://example.com/ombi.
Note: When using a subdirectory it is essential to use PathPrefix instead of Path.
More information here, specifically Path Vs PathPrefix.

    labels:
    - traefik.enable=true
    - traefik.http.services.ombi.loadbalancer.server.port=3579
    - traefik.docker.network=traefik_proxy
    - traefik.http.routers.ombi.rule=PathPrefix(`/ombi`)
    - traefik.http.routers.ombi.entrypoints=https
    - traefik.http.routers.ombi.tls.certresolver=letsencrypt
    - traefik.http.routers.ombi.tls.domains[0].main=*.example.com
    - traefik.http.routers.ombi.tls.domains[0].sans=example.com
    - traefik.http.middlewares.ombi.headers.SSLRedirect=true
    - traefik.http.middlewares.ombi.headers.STSSeconds=315360000
    - traefik.http.middlewares.ombi.headers.browserXSSFilter=true
    - traefik.http.middlewares.ombi.headers.contentTypeNosniff=true
    - traefik.http.middlewares.ombi.headers.forceSTSHeader=true
    - traefik.http.middlewares.ombi.headers.SSLHost=
    - traefik.http.middlewares.ombi.headers.STSIncludeSubdomains=true
    - traefik.http.middlewares.ombi.headers.STSPreload=true
    - traefik.http.middlewares.ombi.headers.frameDeny=true

The following configuration would make Ombi available at https://ombi.example.com.

    labels:
    - traefik.enable=true
    - traefik.http.services.ombi.loadbalancer.server.port=3579
    - traefik.docker.network=traefik_proxy
    - traefik.http.routers.ombi.rule=Host(`ombi.example.com`)
    - traefik.http.routers.ombi.entrypoints=https
    - traefik.http.routers.ombi.tls.certresolver=letsencrypt
    - traefik.http.routers.ombi.tls.domains[0].main=*.example.com
    - traefik.http.routers.ombi.tls.domains[0].sans=example.com
    - traefik.http.middlewares.ombi.headers.SSLRedirect=true
    - traefik.http.middlewares.ombi.headers.STSSeconds=315360000
    - traefik.http.middlewares.ombi.headers.browserXSSFilter=true
    - traefik.http.middlewares.ombi.headers.contentTypeNosniff=true
    - traefik.http.middlewares.ombi.headers.forceSTSHeader=true
    - traefik.http.middlewares.ombi.headers.SSLHost=
    - traefik.http.middlewares.ombi.headers.STSIncludeSubdomains=true
    - traefik.http.middlewares.ombi.headers.STSPreload=true
    - traefik.http.middlewares.ombi.headers.frameDeny=true

The following configuration would make Ombi available at https://media.example.com/request.
Note: When using a subdirectory it is essential to use PathPrefix instead of Path.
More information here, specifically Path Vs PathPrefix.

    labels:
    - traefik.enable=true
    - traefik.http.services.ombi.loadbalancer.server.port=3579
    - traefik.docker.network=traefik_proxy
    - traefik.http.routers.ombi.rule=Host(`media.example.com`) && PathPrefix(`/request`)
    - traefik.http.routers.ombi.entrypoints=https
    - traefik.http.routers.ombi.tls.certresolver=letsencrypt
    - traefik.http.routers.ombi.tls.domains[0].main=*.example.com
    - traefik.http.routers.ombi.tls.domains[0].sans=example.com
    - traefik.http.middlewares.ombi.headers.SSLRedirect=true
    - traefik.http.middlewares.ombi.headers.STSSeconds=315360000
    - traefik.http.middlewares.ombi.headers.browserXSSFilter=true
    - traefik.http.middlewares.ombi.headers.contentTypeNosniff=true
    - traefik.http.middlewares.ombi.headers.forceSTSHeader=true
    - traefik.http.middlewares.ombi.headers.SSLHost=
    - traefik.http.middlewares.ombi.headers.STSIncludeSubdomains=true
    - traefik.http.middlewares.ombi.headers.STSPreload=true
    - traefik.http.middlewares.ombi.headers.frameDeny=true

V3 Specific

The notes regarding Ye Olde V3 Proxy can be found in the archive.
Note: please don't run V3 any more. If you have somehow managed to get V3 from somewhere, replace it with V4.