How to Set Up Nginx as a Reverse Proxy for Apache NiFi

How to Set Up Nginx as a Reverse Proxy for Apache NiFi

How to Set Up Nginx as a Reverse Proxy for Apache NiFi

Apache NiFi is a powerful data flow automation tool, but its default setup — running on its own port, often secured with a self-signed certificate and a clunky hostname — isn’t exactly friendly for production environments. If NiFi is being exposed to a team, a customer, or the public internet, putting Nginx in front of it as a reverse proxy solves a whole list of problems at once: clean URLs, centralized SSL termination, access control, and the ability to run several internal applications behind a single public IP.

This guide walks through everything needed to get Nginx working as a reverse proxy for Apache NiFi, from the basic concept down to production-grade hardening.

What a Reverse Proxy Actually Does for NiFi

A reverse proxy sits between the outside world and NiFi’s internal web server. Instead of clients connecting directly to https://nifi-server:8443/nifi, they hit Nginx on a standard port (80/443), and Nginx forwards the request internally to NiFi.

This matters more for NiFi than for most applications because NiFi is unusually strict about how it identifies incoming requests. NiFi validates the Host header against a list of allowed hostnames, and when it’s placed behind a proxy, it needs to be told explicitly what the “real” external host, port, scheme, and path are — otherwise it will reject requests outright with an HTTP 403 error, or it will generate broken links in the UI (CSS, JS, and API calls pointing at the wrong internal address).

That’s the core challenge with proxying NiFi: it’s not a simple “forward the request and hope for the best” setup. NiFi has to be explicitly configured to trust and understand the proxy.

Requirements Before Starting

Before touching any configuration, make sure the following are in place:

Install Nginx if it isn’t already present:

sudo apt update
sudo apt install nginx -y

On RHEL/CentOS/Rocky:

sudo dnf install nginx -y

Step 1: Configure NiFi to Trust the Proxy

Open NiFi’s configuration file, usually located at /opt/nifi/conf/nifi.properties (adjust the path for the actual install location).

Locate and update the following proxy-related properties:

nifi.web.proxy.host=nifi.example.com,nifi.example.com:443
nifi.web.proxy.context.path=

If running a NiFi cluster, also verify nifi.cluster.node.protocol.port and related clustering settings remain untouched — proxying is only applied to the web UI/API layer, not internal cluster communication.

Restart NiFi after saving changes:

sudo systemctl restart nifi

Step 2: Write the Nginx Configuration

Create a new server block dedicated to NiFi:

sudo nano /etc/nginx/sites-available/nifi.conf

Here’s a complete, production-ready configuration:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 80;
    server_name nifi.example.com;

    # Redirect all HTTP traffic to HTTPS
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name nifi.example.com;

    ssl_certificate     /etc/letsencrypt/live/nifi.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/nifi.example.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    client_max_body_size 100M;

    location / {
        proxy_pass https://127.0.0.1:8443;
        proxy_ssl_verify off;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Port $server_port;
        proxy_set_header X-ProxyScheme $scheme;
        proxy_set_header X-ProxyHost $host;
        proxy_set_header X-ProxyPort 443;
        proxy_set_header X-ProxyContextPath "";

        # WebSocket support (NiFi uses WebSockets for live status updates)
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

        # Long timeouts, since NiFi flows can involve large uploads or long-running requests
        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
        proxy_connect_timeout 60s;
    }
}

A few details worth explaining:

Enable the site and test the configuration:

sudo ln -s /etc/nginx/sites-available/nifi.conf /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

On RHEL-based systems without sites-available/sites-enabled, place the same server block directly inside /etc/nginx/conf.d/nifi.conf.

Step 3: Testing the Setup

Start with a basic connectivity check:

curl -Ik https://nifi.example.com/nifi/

A 200 OK or 302 response indicates the proxy chain is functioning. Then open the URL in a browser and confirm:

If NiFi has single-user or LDAP authentication enabled, log in and verify the session persists across navigation — broken cookie or host header handling often shows up as repeated login prompts.

Troubleshooting Common Issues

403 Forbidden immediately on load This is almost always caused by a missing or incorrect nifi.web.proxy.host entry. NiFi logs (nifi-app.log) will show a line like “The request contained an unexpected Host header.” Add the exact hostname (with port, if non-standard) used in the URL bar to that property.

UI loads but looks broken (no CSS, blank canvas) Usually a missing X-ProxyContextPath header or an actual context path mismatch. If NiFi is served from a subdirectory, both nifi.web.proxy.context.path in nifi.properties and the location block path in Nginx need to agree exactly.

502 Bad Gateway Check that NiFi is actually listening on the port specified in proxy_pass, and that proxy_ssl_verify off is set if NiFi’s cert isn’t trusted by the system CA store. Confirm with:

sudo ss -tlnp | grep 8443

WebSocket connection failures / flow status not updating Double-check the map $http_upgrade $connection_upgrade block is present and that proxy_http_version 1.1 is set. Browser dev tools (Network tab, filtered to WS) will show a failed upgrade if this is misconfigured.

Session keeps dropping / repeated login prompts Verify proxy_set_header Host $host; isn’t being overridden elsewhere, and that clock skew between the Nginx host and NiFi host isn’t causing token validation issues (NiFi uses JWTs with expiration timestamps).

Security Considerations

Since NiFi often has access to sensitive data pipelines, the reverse proxy layer should be treated as a security boundary, not just a convenience layer.

add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Performance Tips

upstream nifi_cluster {
    ip_hash;
    server nifi-node1:8443;
    server nifi-node2:8443;
    server nifi-node3:8443;
}

Real-World Use Cases

Best Practices Checklist

Getting Nginx and NiFi to work together cleanly comes down to one core idea: NiFi needs to be told explicitly what the outside world sees, and Nginx needs to pass that information through consistently. Once those two pieces line up — proxy headers on the Nginx side, nifi.web.proxy.host on the NiFi side — the rest is standard reverse proxy hygiene: TLS, timeouts, and access control.

Exit mobile version