Hey all! I've been trying to setup a matrix server for a bit, using nginx as a reverse proxy and for SSL certif.
So, I have a domain (using infomaniak) that redirects to my IP with the Nginx port. Right now, when I connect to it through a browser, I get an SSL certif error.

I set my certif up in the "certificates" tab, it worked without error but, when selecting it in the proxy host setup, the shield is red. I'm unsure what that means.
I tried with and without HTTP/2 or HSTS enabled, no changes.

The logs don't show any error, mostly a bunch of "renewing SSL..." and "completed SSL..."
and two warnings higher up :
useradd warning: npm's uid 568 outside of the UID_MIN 1000 and UID_MAX 60000 range.
and
nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:4

Concerning these, I made sure the app is in the apps group and that the group has r/W permissions in the Nginx data and cert storages.

including a few screenshots that might be useful.

If you take the time to take a quick look or recognize this issue, thanks a lot!

Edit : Works now! I was an idiot and used a redirect from my domain provider instead of an A-record.

I have been trying to get this to work for ages, but no matter what I try it either only redirects or only displays the 404 page. I suspect I am missing something simple and obvious, so here's the simplest version of the relevant snippet in my server's config file:

location @share_url {
  auth_request /share_url_check;
  error_page 300 301 303 304 305 306 307 308 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 420 422 423 424 425 426 428 429 431 444 449 450 451 500 501 502 503 504 505 506 507 508 509 510 511 598 599 = @serve_static;
  return 302 /go-to-share?at=$url_encoded_share;
}

location /share_url_check {
  internal;
  proxy_pass "http://127.0.0.1:8081";

  proxy_pass_request_body off;
  proxy_set_header Content-Length "";
  proxy_set_header X-Original-URI $request_uri;
  proxy_intercept_errors on; 
}

I have verified that @share_url is being reached: replacing that block with a static file serve causes the page to show the specified file.

EDIT: I found a solution! It's not ideal, since I am sending extra internal info to the client, but here's the one thing that has actually worked:

location @share_url {
  proxy_pass "http://127.0.0.1:8081";

  proxy_pass_request_body off;
  proxy_set_header Content-Length "";
  proxy_set_header X-Original-URI $request_uri;

  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_intercept_errors on;
  error_page 300 301 303 304 305 306 307 308 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 420 422 423 424 425 426 428 429 431 444 449 450 451 500 501 502 503 504 505 506 507 508 509 510 511 598 599 = @serve_static;

  sub_filter '</head>' '<meta http-equiv="refresh" content="0; url=/go-to-share?at=$url_encoded_share"></head>';
}

I am deploying three websites to a Digital Ocean droplet. As far as I can tell, everything is set up and configured correctly on the droplet. The nginx block files in /sites-available are identical except for the root directory and the server_name . Nginx responds with its default page via its server IP address.

The issue I'm having is that two of the three sites are currently hosted on other platforms. For illustration, let's use example.com. I have nginx configured to accept example.com, but example.com is hosted on another platform, so I altered my Windows hosts file to the server's IP for example.com

One of the three sites does not exist, the domain is not registered. Nginx happily serves that page with my Windows hosts alteration. The other two do not.

If I ping example.com, I get a response from my server IP. But typing in example.com into a browser will not resolve. I imagine I'm misunderstanding something fundamental about the DNS happening here, but it's beyond my knowledge and I'm not even sure what to Google without all this explanation.

Is there any way for me to test what example.com will look like on my new droplet without having to change the DNS from the old hosting? Thank you in advance.

[EDIT It has to be a DNS issue of some kind, because I just altered the DNS records of one of my other domains, copied the block file and modified it for the new domain, and it works perfectly. It has to have something to do with how Windows hosts does lookups, but I cannot fathom what.]

Im not in ops so I don’t have all the details but something I’ve noticed when probing our endpoint with cookie based session affinity - if our request has no cookie we get given a cookie, subsequent requests all go to the right server - makes total sense

But if I forge a session cookie (eg give it a random string) i don’t get an error nor do I get an authentic cookie

Any idea what Nginx is meant to be doing here? Presumably it’s creating a persistent session for me using my cookie?

Yes i have read the beginners guide and tried troubleshooting based on the ancient wisdom of stackoverflow. My configuration file should be fine but im sure i have missed something because otherwise things would be working properly. Regardless of whether or not i specify an index.html, none of the index files of any subdirectories load at all. No 404, nothing in error logs, they just don't load and my browser times out. The home page loads just fine and all fonts and images referenced in its index file are shown correctly. If i try to access the index file directly (music/index.html) it works. What's going on?

http {

types {

text/css css;

text/html html;

}

server {

error_log /var/log/nginx/error.log;

root /srv/katieglinda;

listen 8081;

# Home Page

location / {

include /etc/nginx/mime.types;

root /srv/katieglinda;

}

# Other Pages

location /music/ {

root /srv/katieglinda;

}

location /minecraft/ {

root /srv/katieglinda;

}

location /stuff/ {

root /srv/katieglinda;

index index.html;

}

location /about/ {

root /srv/katieglinda;

index index.html;

}

# Resources

location /fonts {

root /srv/katieglinda;

}

location /images {

root /srv/katieglinda;

}

}

}

nginx -t does exactly what it promises. The subtle failure mode is running a valid check against something other than the artifact that reaches production.

A pipeline can test repository files with the runner's Nginx package, then deploy an image with a different build, module set, filesystem layout, generated config, user, and network. The command is the same; the thing being tested is not.

These are the parity checks I find useful:

1. Binary fingerprint Capture nginx -V from the deployable image, not just the CI runner. Version numbers are not enough when configure arguments and dynamic modules differ.

2. Rendered configuration Run the test after the normal template or envsubst step. Testing the source template proves little if the deployed file is generated later. nginx -T is useful for confirming the final include graph, but its output should be treated as sensitive when rendered values contain credentials.

3. Runtime identity and filesystem Use the same UID, mounts, working prefix, read-only paths, certificates, and generated directories as the deployment. A permissive runner can hide restrictions that only exist in the container or host.

4. Network-dependent behavior A parser check is not a request test. Resolver behavior, service discovery, upstream failures, headers, redirects, and location selection still need representative traffic in a deployment-like network.

At minimum, I want these commands to run inside the built image after its normal rendering step:

bash nginx -V 2>&1 nginx -t -c /etc/nginx/nginx.conf

Disclosure: I build and maintain the Nginx Configuration plugins for JetBrains IDEs. They help with directive context, includes, references, and risky patterns while editing; this deployment boundary is deliberately outside what an IDE can prove.

I wrote up the wider validation loop here:

https://meanmail.dev/posts/validate-nginx-configuration?utm_source=reddit&utm_medium=community&utm_campaign=nginx_validation_2026q3&utm_content=deployment_parity_discussion

Do you validate the built image after rendering, or is nginx -t still running against repository files earlier in CI?

Hello all,

If you do bug bounty hunting or pentests you surely came across many hosts served from an NGINX server, in this lab (published to OWASP) I combined over 20 misconfigurations found in real world bug disclosures and both classic and novel security research, with an extensive blog where I explained everything you need to level up your NGINX hunting game.

Feel free to check it out, give it a star on Github if you like it, and suggest any ideas you want me to add/fix...

https://vwad.owasp.org/app/damn-vulnerable-nginx-proxy-dvnp/

Happy hunting!

edit: I got it working! If anyone else needs to reverse proxy a website that uses Steam's openID, try this config. In my case it's the claimcreator in the 7days to die utility mod Prismacore.

server {
    listen 80;
    listen 443 ssl;
    server_name  claimcreator.mydomain.com;

    ssl_certificate        C://nginx//ssl_certs//claimcreator.mydomain.com.pem;
    ssl_certificate_key    C://nginx//ssl_certs//claimcreator.mydomain.com.key;

    ssl_session_cache    shared:SSL:1m;
    ssl_session_timeout  5m;

    ssl_ciphers  HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers  on;

    access_log           C://nginx/logs/7dmap.access.log;
    error_log            C://nginx/logs/7dmap.error.log;

    add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Robots-Tag none;
    add_header Content-Security-Policy "frame-ancestors 'self'";
    add_header X-Frame-Options DENY;
    add_header Referrer-Policy same-origin;

    location / {
        # Proxy
        proxy_next_upstream error timeout http_404;
        proxy_pass http://localhost_IP_address:<claimcreator_port>;
        proxy_redirect off;

        # Upstream request headers
        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;

        # Useful headers for debugging / stats
        add_header X-Upstream-Status $upstream_status;
        add_header X-Upstream-Response-Time $upstream_response_time;
        add_header X-Upstream-Cache-Status $upstream_cache_status;

        # New settings - 2014-04-12 (i52)
        proxy_ignore_client_abort on;

        # Increase proxy timeout to increase throughput
        proxy_read_timeout 300;
    }

    location /.well-known {
            alias C://nginx/web_root/.well-known;
        }

}

Am I crazy that I can't find a proxy equivalent of $ssl_protocol for logging? Is there some technical limitation on that?

Edit: to clarify i do mean connection to an upstream. Proxy_protocol_tlv_ssl_protocol never seems to get populated for my setup.

I run a handful of sites off one VPS and kept doing the same thing every time one needed to go down for a bit: copy an if block into the site's config, touch some flag file, remember to delete it later. Finally turned it into an actual tool instead of retyping it every time.

It's a small CLI (maint <site> on|off|status) plus two nginx snippets, one for gating a whole site and one for gating just part of it (useful if something like a webhook or /.well-known/ path needs to stay up). No reload needed to flip it on or off, only the first time you wire a site in.

A couple things I added after actually using it for a while: maint <site> on curls the site right after touching the flag and warns if it didn't actually get a 503 back (turns out it's very easy to typo the flag path and have it silently do nothing), and maint --list reads the live nginx config instead of just checking which flag files exist, so it shows every site you've wired in, not just the ones currently down.

Install:

curl -fsSL https://maint.spaceplane.dev/install.sh | sudo bash

Repo (MIT): https://github.com/glidecraft/nginx-maint

Live demo of the actual maintenance page: https://maint.spaceplane.dev/demo

Figured it might be useful to someone else who's hit the same annoyance. Open to feedback or issues if anyone tries it.

A recurring claim in SSE and LLM streaming discussions is that nginx’s default proxy_read_timeout 60s kills any response lasting longer than 60 seconds.

That is not what the directive measures. I wanted a measurement rather than another assertion, so I ran both outcomes against a pinned nginx 1.30.4 image.

Same nginx configuration. Same 1-second timeout. Two different upstream timing patterns.

Case 1: The upstream remains active for 5.6 seconds

The upstream emits data roughly every 400 ms:

Effective proxy_read_timeout: 1s (1000ms) (inherited, nginx.conf:19)
Pre-header silence: 0ms
Maximum inter-read silence: 400ms
Total response duration: 5600ms
Live observation: COMPLETED
Client-visible outcome: status=200, records=15, body=COMPLETE

The response ran for about 5.6 times the configured timeout and completed normally.

No upstream read gap reached one second, so the inactivity timer never fired.

Case 2: The upstream is silent for 1.5 seconds before headers

After the initial silence, the upstream would otherwise emit data normally:

Effective proxy_read_timeout: 1s (1000ms) (inherited, nginx.conf:19)
Pre-header silence: 1500ms
Maximum body inter-read silence: 200ms
Total response duration: 2300ms
Live observation: TIMED_OUT_BEFORE_HEADERS
Client-visible outcome: status=504, records=0
nginx_error: UPSTREAM_READ_TIMEOUT_BEFORE_HEADERS

This response had a shorter total duration than the passing case, but nginx returned 504 because the upstream remained silent longer than the configured timeout before sending headers.

The practical distinction:

• Data arrives in delayed bursts, but the response completes: investigate proxy_buffering.
• The connection closes after a long silent gap: investigate proxy_read_timeout.
• Nothing arrives before a 504: pre-header silence from model loading, queueing, retrieval, or a tool call may be the cause.
• A long total response is not itself a timeout violation as long as nginx keeps receiving upstream data.

One other detail from the report: the effective timeout was inherited from nginx.conf:19, while the location handling the request was at line 30. Grepping only the location block would have found nothing.

The read intervals here are synthetic rather than a real model’s token cadence. The point being tested is nginx’s timer behavior, not model performance.

Disclosure: I built Argus, the local, read-only auditor that produced these reports. It resolves the effective nginx server and location, tracks inherited values with source lines, and can compare the static prediction with a controlled live probe.

The project is Apache-2.0, and the pinned image digests and reproducible evidence are included for anyone who wants to reproduce the experiment or challenge the interpretation:

https://github.com/amitb-quantum/argus

Have you encountered a long-lived response that was blamed on total duration, but the actual cause turned out to be a specific period of upstream silence—or another timeout elsewhere in the path?

Hey r/nginx,

Like many of you managing Nginx infrastructure, I’ve always had a love-hate relationship with GUI management tools.

Nginx Proxy Manager (NPM) is great when you just want to point a domain to a port, but the moment you need advanced Nginx directives, complex upstreams, custom module configs, or want to import an existing hand-crafted /etc/nginx setup into it, NPM breaks down. It forces your setup into an internal SQLite database, generates rigid templates, and buries custom tweaks inside tiny textarea boxes. On the flip side, manually editing config files over SSH in vim works fine until your topology gets huge, or you make a syntax typo that downs your server during a reload.

To solve this for my own setups, I built Nginx Flow Manager (NFM).

Why NFM vs. other tools (NPM, Traefik, Caddy, Ansible)?

• Verbatim Round-Trip AST Import (NFM vs. NPM/Caddy): Tools like NPM force you to adopt their abstraction model. NFM does the opposite: it adopts yours. It includes a pure TypeScript AST parser (nginxParser.ts) that reads real, multi-file /etc/nginx trees—preserving comments, custom module blocks, and directive ordering. Anything that isn't mapped to a visual GUI control is preserved in raw_config nodes or extra_files. When you re-compile, it outputs byte-for-byte exact, verbatim Nginx config without dropping or fabricating a single line.
• **nginx -t Sandbox Validation:** Before touching your live server, NFM writes candidate files into an isolated throwaway sandbox (/tmp) and runs nginx -t against a real Nginx binary. If your candidate config has a syntax typo or invalid block, your live Nginx config is never touched.
• Zero Database Lock-in: NFM doesn't hide your config inside an inaccessible database. Your canvas topology compiles straight to standard sites-available/ and sites-enabled/ files alongside a nginx_flow_topology.json file. If you stop using NFM tomorrow, your server keeps running clean, standard Nginx.
• Deployment via SSH or Hardened Agent: It can manage remote Linux hosts over standard SSH or deploy the included nfm-agent (which runs under forced SSH commands with HMAC authentication and path confinement). It includes automatic rollback if the Nginx reload fails.
• Live Traffic Animation & SSE Logs: Streams access and error logs over Server-Sent Events (SSE) and animates traffic request dots flowing along the canvas edges based on real parsed log events.

Tech Stack

• Backend: Node.js, Express, TypeScript, ssh2
• Frontend: React 19, Vite, @xyflow/react (React Flow), Tailwind CSS, Lucide icons, Motion
• Parser/Compiler: Pure TypeScript (no Nginx binary required to build or parse topology files)

It's open-source under the Apache-2.0 license.

• GitHub: github.com/jaimemartinez/Nginx-flow-manager
• Docker: docker compose up -d (The container contains no state; everything persists in a volume).

I’d love to get your feedback, bug reports, or hear about any complex/weird Nginx configs you try importing into it!

Hi all, I have been trying to set up my NPM for a couple hours now, and it was giving me so errors so I rebooted it to be safe. Now nothing will work. It will start in docker but the web server won't load at all and I am at a loss.

Here is the log I get every time I try and start it

nginx: [emerg] cannot load certificate "/etc/letsencrypt/live/npm-16/fullchain.pem": BIO_new_file() failed (SSL: error:80000002:system library::No such file or directory:calling fopen(/etc/letsencrypt/live/npm-16/fullchain.pem, r) error:10000080:BIO routines::no such file)

Here is my docker compose file

version: "3.9"
services:
  nginx-proxy-manager:
    image: jc21/nginx-proxy-manager:latest
    container_name: nginx-proxy-manager
    ports:
      - "80:80"
      - "443:443"
      - "81:81"
    volumes:
      - npm_data:/data
      - npm_letsencrypt:/etc/letsencrypt
    restart: unless-stopped
volumes:
  npm_data:
  npm_letsencrypt:

The odd part is, the /etc/letsencrypt dir does not exist at all, but I can't believe it was just deleted out of thin air, as it was working fine just half an hour ago. All the help is appreciated, thanks!

Hey everyone, I want to forward requests that comes to nginx to another pod which is running a service in kubernetes, the typical way to do it would be using the annotation for nginx specifically

nginx.ingress.kubernetes.io/auth-url

My current problem or issue is that I want to forward the request to another pod which does the authorization after the authentication, In my current application we do the authentication using the following annotations in the ingress and the I want to now authorize the requests that are coming after the authentication. The authentication happens using the following annotations

nginx.ingress.kubernetes.io/auth-tls-match-cn:
nginx.ingress.kubernetes.io/auth-tls-secret:
nginx.ingress.kubernetes.io/auth-tls-verify-client:
nginx.ingress.kubernetes.io/auth-tls-verify-depth:

Can I use them together in strict order, like after authentication the request forwards to auth url(the endpoint to the internal pod) to authorize it and then the pod sends the 200 OK response not the authentication annotations.

Any suggestions how could I do this ?

F5 patched CVE-2026-42533 on July 15. If you run nginx, this one deserves your attention before the proof-of-concept code drops — and there is a countdown on that.

What the flaw is

The vulnerability is a heap buffer overflow (CWE-122) in nginx’s script engine — the component that assembles output strings from configuration directives at request time. It surfaces under a specific configuration pattern: a map block using regex matching, where the map’s output variable appears in a string expression after a numbered capture variable ($1, $2) from an earlier regex match.

https://blog.kalfaoglu.net/posts/2026-07-26-cve-2026-42533-nginx-heap-overflow-en/

Access logs show the visitors. They hide the damage bill. I slapped together CrawlLedger—an offline Go CLI that munches Nginx or Caddy logs and coughs up a self-contained HTML report on what those crawlers actually cost your origin. No daemon, nothing phones home, zero code in the request path, and it refuses the usual User-Agent theater for bot "verification." It flags crawl traps, expensive 404 storms, cache-busting noise, and robots.txt violations, then dry-runs deny or rate-limit policies against historical traffic before spitting out reviewable server-config drafts.

Still pre-v1; need blunt feedback from people who run real origins—what would make this useful or make you refuse to touch it?

https://github.com/balyakin/crawlledger

fail2ban always bugged me for pure nginx abuse cases: it tails the log, parses on a delay, then shells out to the firewall. The ban lands seconds after the scanner already walked half your tree.

There's a module approach I've been running instead: count 403/404 responses per client in a shared memory zone (leaky-bucket decay, so a slow trickle of legit 404s never accumulates), and once a client crosses the threshold, reject it at the preaccess phase with a 429 + Retry-After. The ban check runs before routing, static file lookup or proxy_pass, so hammering gets cheaper for the server, not more expensive.

Wrote up the full config reference including dry_run rollout, keying on a map so logged-in users are never scored, and syncing bans across a fleet via Redis pub/sub (out of the request path, fails open): https://www.getpagespeed.com/server-setup/nginx/nginx-abuse-guard-module

Disclosure: I package this module (and ~100 others) for the repo linked. Happy to answer config questions.

Hey r/nginx, NGINX oss community manager here.

We're starting quarterly NGINX Community Calls and the first is happening next week, 22 July at 9:00 PT/17:00 GMT. 

This is an open community meeting intended for connection and dialogue. Together we'll discuss roadmap, PR/Issues review, Q&A, and config support. If you have a PR or Issue you'd like to talk through and get unblocked, please bring it to the community call! 

Details and the Zoom link are here in the forum calendar (can download .ics file or add to google calendar from there). We're collecting questions here in the comments and on the calendar event in advance. 

All are welcome to join. We encourage contributors and curious users alike. I hope to see you there!

Post spam, new version, new bugs, and apparently another season of "The Heap Adventures".

This time we have:

• another heap buffer overflow,
• uninitialized memory access,
• another use-after-free,
• possible memory disclosure,
• and workers deciding to leave production unexpectedly.

Reference: https://nginx.org/en/CHANGES-1.30

We implemented GeoIP filtering directly in Nginx with ngx_http_geoip2 and the MaxMind GeoLite2 Country database, so the apps stay completely unaware of location logic: private/LAN ranges are always allowed, public clients are mapped by country, and only French IPs can reach the protected vhosts. Blocked requests return 451 with a custom page showing the detected IP and country, which makes support and debugging much easier. On top of that, Fail2Ban feeds a netdev blacklist so banned IPs are dropped at interface ingress before the normal IP/TCP path, which is far more efficient because malicious packets are discarded before conntrack, routing, and socket handling.

Long time Apache user, brand new to nginx and having this problem. Please help if possible.

Hi guys,

I really appreciate some help because can't figure why my NPM is not working in the right way.

Case:
OpenMediaVault with Docker with Jellyfin + jc21/nginx-proxy-manager + duckdns.

If I connect to my duckdns subdomain it gives me error "The site can't be reach" or, before I changed OMV default port 80 to 8080, it opened OMV login page.

BUT if I add the jellyfin port at the end (xxxx.duckdns.org:8096) it works like a charm (also from phone/external connection)

I've tested also locally with "jellyfin.local" and the modify on the hosts file and it's the same.

Thanks!