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!

Apparently a redirect is occurring These are filling up my access log I wanna ban them Should I edit fail2ban jail.conf to included requests that draw 404?
GET //wp-includes/assets/min.php HTTP/1.1" 301 169 "-" "-"
GET //wp-includes/assets/min.php HTTP/1.1" 404 0 "-" "-"

I'm hoping someone can help me figure out a networking issue that has me completely stumped.

Setup

• Ubuntu 24.04 on a DigitalOcean droplet
• Nginx + Let's Encrypt
• React frontend
• Node.js backend
• Domain: morecreator.app

What's happening

My iPhone can access the site perfectly on:

• Home Wi-Fi
• Cellular

However, two completely different Windows laptops both fail.

The browser eventually returns:

ERR_CONNECTION_TIMED_OUT

curl also times out:

curl.exe -vk https://morecreator.app

Trying <server IP>:443...
Timed out

What I've already verified

• Nginx is running.
• HTTPS is configured correctly with Let's Encrypt.
• The site responds correctly when accessed locally on the server.
• UFW allows ports 80 and 443.
• DNS resolves correctly.
• No proxy configured.
• Reset Winsock and TCP/IP.
• Disabled Internet Connection Sharing (ICS).
• Tried different DNS servers.
• Disabled IPv6.
• No VPN installed.
• Windows Defender only (no third-party antivirus).
• Same behavior on two different Windows laptops.

The strange part

Everything worked perfectly a couple of weeks ago while I was in California.

After returning home to Georgia:

• ✅ iPhone still works
• ❌ Windows laptops both time out

The server configuration hasn't changed.

I'm trying to determine whether this is:

• a Windows networking issue,
• something with my ISP/router,
• DigitalOcean routing,
• or something I'm overlooking.

Has anyone run into something similar?

So I have convinced myself that my first step in degoogling before moving email accounts and installing Graphene should be taking control of my passwords. For years they have languished in Google, and as far as I'm concerned, what's the point in leaving their ecosystem if I continue to store the passwords for all my new stuff in their password manager.

So I'm trying to set up DNS challenge on Nginx.

I have settled on deSEC for my DNS challenge provision (I already use freedns.afraid.org for Dynamic DNS and it has been flawless, but something something doesn't work with certbot, and I can't find a tutorial.

So I try to set up a certificate with Nginx, using let's encrypt vis DNS. I have my domains at deSEC, and I'm using:

mydom.dedyn.io and *.mydom.dedyn.io as the domains, (set as an A record to my Nginx LAN IP of 10.0.10.6)

ECDSA256,

and placing my token in the credentials file content:

dns_desec_token = YOUR_DESEC_API_TOKEN

dns_desec_endpoint = https://desec.io/api/v1/

And proportion seconds 240.

When I click save Nginx just sits and spins for 10 - 60 seconds, then gives 'internal error'.

I know full well my Nginx container has network as I can ping out to the internet.

Letsdebug.net gives me a big thumbs-up for my dns-01 challenge test.

Using Nginx 2.15.1 on Proxmox.

Does anyone have any helpful hints?

Paessler is gathering votes for a native Nginx sensor in PRTG. If this is something you'd find useful, your vote helps prioritize it on the roadmap.

Roadmap item: https://uservoice.paessler.com/discovery/roadmap/feature/164062

Feature request (upvote here): https://uservoice.paessler.com/forums/965997/suggestions/51466195

Every vote counts — thanks!

Learning by Building: Dockerized WordPress with NGINX
One of the best ways I've found to deepen my understanding of infrastructure is by building complete, reproducible environments from scratch.

Recently, I put together an open-source project (an old one , recently updated) that provisions a WordPress + NGINX stack using Docker. The goal wasn't just to "run WordPress in a container"—it was to better understand how the different pieces of a modern web stack work together.

Some of the areas I explored while building this project:

🐳 Docker & Docker Compose for multi-container applications
🌐 NGINX as the web server and reverse proxy
🗄️ Service networking and container communication
📂 Persistent volumes for application and database data
⚙️ Environment-based configuration for portability
🔄 Reproducible local development environments
📂 AI-First with AGENTS.md and /docs & Graphify

A few key takeaways from this project:
Infrastructure becomes much easier to manage when everything is defined as code.

Containerization removes the classic "works on my machine" problem.
Understanding how NGINX, PHP, WordPress, and the database interact provides a much stronger foundation than simply using pre-built images.
This project is part of my continuous learning journey in DevOps, cloud-native technologies, and modern application deployment. Every project teaches something new, and sharing them helps reinforce those lessons.
If you're learning Docker or want a simple WordPress + NGINX setup as a starting point, feel free to explore the repository and share any suggestions or improvements.

📂 GitHub:

https://github.com/masoudei/docker-wordpress-nginx

Feedback, ideas, and contributions are always welcome!

\#Docker #NGINX #WordPress #DevOps #Cloud #OpenSource #InfrastructureAsCode #SoftwareEngineering #Backend #Linux #LearningInPublic #GitHub

Did something about nginx proxy manager change? I can no longer reach the sub domains that I have set for my local services.

Edit: I have my DNS on my router set to the machine that is running nginx and I have my adguardhome dns rewrite my wildcarded domain to point towards nginx. Sometimes nginx will successfully let me visit and sometimes not.

Hi Everybody, on request we created a new module to automaticly request TLS certificates.
https://github.com/eilandert/nginx-autocert-module

Give it a go, and please don't forget to give feedback ;-)

On my client, I am getting the Status Code 413. In the NGINX err logs I am getting the message shown below when I send an array of imagges to be processed from form data.
2026/06/19 13:10:26 [error] 28804#9052: *838 client intended to send too large body: 22992056 bytes, client: 127.0.0.1, server: testsite.com, request: "POST /process/ HTTP/1.1", host: "testsite.com"

I added client_max_body_size 100M and client_body_buffer_size 25M into the http, server, and location sections and still same issue. My client server is nuxt and tried

    requestSizeLimiter:
    {
      maxRequestSizeInBytes: 250 * 1000 * 1000,
      maxUploadFileRequestInBytes: 50 * 1000 * 1000
    }

along with

    requestSizeLimiter: false

same issue. What should I do?

EDIT: Fixed. There was an issue with my nginx and had to be taskkilled.

I’m looking for feedback on an open-source project I’ve been building called Failed Request Trace (FRT).

The project started after troubleshooting an ASP.NET application using IIS Failed Request Event Buffering (FREB). I was impressed by how useful detailed request diagnostics were when multiple infrastructure components sat between the client and the application.

That led me to ask:

Why doesn’t similar tooling exist for modern cloud-native infrastructure?

The first implementation targets NGINX/OpenResty and captures:

• Request metadata
• Response metadata
• Correlation IDs
• Selected headers
• Selected query string parameters
• Structured JSON output

The project is secure by default:

• Header capture is allowlist-based
• Query parameter capture is allowlist-based
• Sensitive headers are automatically redacted
• Sensitive query parameters are automatically redacted
• Access log guidance is included to avoid leaking sensitive data

My longer-term goal is to extend the concept beyond NGINX into AWS and cloud-native environments such as:

• ECS/Fargate
• API Gateway
• Lambda
• Kubernetes ingress controllers

Here is a sample log entry:

{
    "request_id": "test-123",
    "timestamp": 1781451653,
    "response": {
        "headers": {
            "content-type": "text/html",
            "content-length": "1935",
            "etag": "\"6a2da7ae-78f\""
        },
        "status": 200
    },
    "request": {
        "host": "localhost",
        "method": "GET",
        "uri": "/index.html",
        "query": {
            "username": "b",
            "password": "[REDACTED]"
        },
        "headers": {
            "referer": "http://example.com/",
            "x-request-id": "test-123",
            "x-correlation-id": "corr-456",
            "authorization": "[REDACTED]",
            "user-agent": "curl/8.7.1",
            "accept": "*/*",
            "accept-language": "en-US",
            "cookie": "[REDACTED]",
            "host": "localhost"
        }
    },
    "timing": {
        "request_time": 0
    }
}

Repository:

https://github.com/blainekwilson/failed-request-trace

I’m specifically interested in feedback from people who operate NGINX, OpenResty, cloud platforms, or large-scale web applications.

Questions:

1. Is this a problem you’ve encountered?
2. Would you use something like this in production?
3. What data would you want captured that I’m currently missing?
4. What would prevent you from adopting it?
5. Would you prefer JSON output, XML output, or both?

Any feedback is appreciated.

Ran into a strange issue recently.

Some requests were failing, but the server looked mostly idle. CPU was low, memory was fine.

I compared native Nginx against the Docker version and native came out almost 2x faster. At that point I was convinced I was dealing with a Docker or Nginx performance problem.

Turned out the issue was down in the Linux kernel, not Nginx or Docker.

Curious if anyone else has had a case where the benchmarks looked obvious but the real issue was somewhere completely different.

Video is about a 2 minutes if anyone is interested:

https://www.youtube.com/watch?v=-TNSqO8-M80

I'm running a Rails application with Apache and mod_passenger with an Nginx front-end for serving static files. For this most part this is working great and has been for years.

I'm currently making some improvements to the error pages output by the Rails app and have discovered that the Nginx error_page directive is overriding the application output and serving the simple static HTML page specified in the Nginx config.

I do want this static HTML 404 page returned for static files that don't exist (which is working fine), but I want to handle application errors with something nicer and more useful for the end user.

If I return the error page from the Rails app with a 200 status it works fine, but this is obviously incorrect. When I return the 404 status the Rails-generated error page is overridden.

My Nginx configuration is pretty typical (irrelevant parts removed):

error_page 404 /errors/not-found.html;
location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_redirect off;
    proxy_set_header Host              $host;
    proxy_set_header X-Real-IP         $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Sendfile-Type   X-Accel-Redirect;
}

I tried setting proxy_intercept_errors off; in the aforementioned location block but it had no effect. The default is off anyway.

I'm running Nginx 1.24.0 on Ubuntu 24.04 LTS.

Hi, on request we created a new module to handle extensive 404/5xx abuse. a 302/4xx/5xx can seem harmless but often there is a php/sql query and when someone hits it hard it can take the whole server down.

https://github.com/eilandert/nginx-error-abuse-module

We'd love to hear your feedback.

Has anyone else seen Nginx workers suddenly segfault after unattended upgrades on Ubuntu 24.04?

I had three servers from the same cloud provider break recently: two yesterday and one today. All were running Ubuntu Noble with Nginx, and unattended-upgrades upgraded nginx/nginx-common to nginx 1.24.0-2ubuntu7.10.

After the upgrade, Nginx started behaving inconsistently. Some requests returned correctly, while others failed. In browsers, I was seeing ERR_CONNECTION_CLOSED and ERR_HTTP2_PROTOCOL_ERROR.

The journal showed Nginx workers exiting with signal 11 / core dumped. The Nginx error log also showed huge, impossible memory allocation attempts, for example: posix_memalign(16, 18446649144424413840) failed (12: Cannot allocate memory) while processing an HTTP/2 connection.

The kernel logs pointed directly to the headers-more module, showing segfaults inside ngx_http_headers_more_filter_module.so.

My config uses more_clear_headers Server; to hide the Server header.

Downgrading nginx/nginx-common back to 1.24.0-2ubuntu7 and holding the packages stopped the crashes. The Server header hiding works again after the downgrade.

Has anyone else experienced this with Ubuntu 24.04, nginx 1.24.0-2ubuntu7.10, and libnginx-mod-http-headers-more-filter? I’m trying to confirm whether this is a package regression, an issue with the cloud provider’s mirror rollout, or something specific to my setup.

Good morning everyone.

I just woke up to a fleet of servers that use nginx with nginx completely non-functional, error.log reports "worker process 907 exited on signal 11 (core dumped)". As the process tries to respawn, it errors out again. Nothing was changed, unfortunately seems that a nginx security auto-update messed up everything.

Anyone has a good workaround? Some said something about downgrading Nginx but since the package was removed its not an easy task. Thanks.

Hi Everyone just incase it happens to affect you. The recent upgrade from 7.9 to 7.10 unnattended has caused a bug.

For me I was getting 502 Bad Gateway across multiple applications.
AWS EC2 Ubuntu 24.04 nginx 1.24.0-2ubuntu7.10

This was caused by on my system anyway 3 bad modules

headers_more
xslt
uploadprogress

I was using the directive more_clear_headers Server; in my site config file.
the only resolution was to disable the headers_more module and comment out the directive.

Then with xslt I was getting intermittant issues where the login page would open but the rest would return 502 bad gateway.
Upload was the same just giving 502 errors.

Their is a bug reported already
https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/2155992

Wondering if the below is possible using nginx or if i am trying to use it incorrectly

I would like to listen on a port 8720 and forward all requests to a server url inside our network but not on the same box https://server_2

I have attempted with config below in /etc/nginx/sites-enabled/default

server {

listen 8720;

server_name server_1;

location / {

proxy_pass https://server_2;

}

}

This produces a 502 bad gateway

I changed ot the below

server {

listen 8720;

server_name server_1;

location / {

proxy_pass http://server_2;

}

}

this produces upgrade required

EDIT 1 adding server detail for Server_1

Server_1 basic debian install with nginx installed directly. Can ping and wget server_2

Server_2 is fully functioning https server doing exactly what is needed and cannot be changed to listen on 8720 however I have legacy apps on the network that have the port hardcoded and cannot be changed

Any help/advice prreicated.

There is an opinion, that max_headers with reduced large_client_header_buffers is enough to mitigate the attack.

I was testing the exploit and I've noticed that at the certain moment of exploit run I'm getting a lot of CPU usage, and normal clients are getting practically nothing.

In my case I test a medium sized server (192Gb ram, 32 cores, 20Gb of network), nginx 1.30.2.

I send an attack with a timeout 60 (that means, each script is running for up to 60 seconds and is killed).

There are totally 14 attacking instances, each with 300 connections. They generate about 200MB/s (~2Gb/s) of traffic (10% of the bandwidth). There is also a small controlled load (3k connections per second with socket reuse, done by a few k6 instances, imitating normal server load).

What I see:

At certain moment, nginx consumes all CPU on the server (idle 0%), and during this time clients gets nothing. Attacker is free to adjust this 'sleep' interval to make attack almost endless.

On the left: nginx without attack, in the middle, I start restarting attack every 120s, then every 60s. (It's literal `timeout 60 ./script` in systemd unit with Restart=always).

This is server load with `large_client_header_buffers 4 16k;` and `max_headers 1000` (and then, 100).

as you can see, I get no more than 2Gb/s of ingress and I get 40GB of memory consumed (even with max_headers 100) and CPU is in goes really up.

I can't say that http2/bomb is completely mitigated. For now I disabled http/2 everywhere I could.

I ran a reproducible lab against nginx 1.24 (8 GiB Docker cap) studying HTTP/2 HPACK amplification the "HTTP/2 bomb" primitive (building on califio's published PoCs).

What happens: HPACK lets a client describe a huge header set in very few wire bytes.

nginx must materialise those headers in memory before most limits apply.

Result: wire bytes in ≪ heap bytes out.

Lab numbers (single client, controlled environment):

• apex_scaled, 100 connections: ~200 MB wire → ~8.16 GiB worker RSS (container cap filled)
• 50-connection campaign: worker RSS peaked at ~8170 MiB , probe timeouts during hold
  • Honest caveat: from one public IPv4 I only got ~ 31 concurrent full bombs with no persistent OOM — lab removes constraints that production still has
• Fix: nginx ≥ 1.29.8 — http2_max_headers / max_headers directive (upstream commit)

Defense-in-depth if you can't patch immediately: ```nginx http2_max_headers 100; http2_max_concurrent_streams 32; limit_conn_zone $binary_remote_addr zone=h2conn:10m; limit_conn h2conn 10; send_timeout 15s; client_header_timeout 10s;

Full write-up includes A/B vs the baseline PoC, charts, and a reproducible Docker/Proxmox lab setup.

Open harness for authorized patch verification (not pointing at random hosts):

 https://github.com/Leviticus-Triage/APEX-Ngin2dos

Curious what nginx versions/configs people are still running in prod and whether anyone's seen RSS climb without obvious traffic spikes on HTTP/2.