Why NGINX’s Hot Reload Falls Short and How APISIX Solves It

NGINX Overview

NGINX is a cross‑platform open‑source web server written in C, powering over 40% of the top‑1000 websites worldwide. Its event‑driven, fully asynchronous I/O and efficient memory management give it high concurrency performance.

Highly modular design with many official and third‑party modules.

BSD license encourages community contributions.

Supports hot reload for 24/7 service.

What Is Hot Reload?

Hot reload means updating server configuration without disrupting client connections, which is essential in cloud‑native microservice environments where services change frequently (e.g., domain switches, upstream updates, IP blacklist changes).

NGINX Hot‑Reload Mechanism

Running

nginx -s reload

sends a HUP signal to the master process. The master opens new listening sockets, spawns new worker processes, then tells the old workers to quit gracefully. New connections go to the new workers while old workers finish existing requests.

Drawbacks of NGINX Hot Reload

Frequent reloads can cause connection instability and business loss. When a reload occurs, the old worker continues processing existing connections but aborts them after the current request, which may drop in‑flight traffic.

Old workers may linger for a long time. For protocols like WebSocket or raw TCP/UDP proxying, NGINX cannot determine when a connection is truly finished, so the old worker stays alive until connections timeout or close, potentially for minutes or half an hour, leading to resource waste or OOM.

<code># Example of lingering old workers
nobody 6246 6241 0 10:51 ? 00:00:00 nginx: worker process
nobody 6247 6241 0 10:51 ? 00:00:00 nginx: worker process
...
nobody 7995 10419 0 10:30 ? 00:20:37 nginx: worker process is shutting down
</code>

When reload frequency reaches dozens or hundreds of times per hour, this model becomes untenable.

In‑Memory Hot‑Reload Solution with Apache APISIX

APISIX, built on NGINX + Lua and using etcd as a configuration center, provides a cloud‑native, fully dynamic API gateway. Configuration changes (upstreams, routes, plugins, IP black‑/whitelists) take effect instantly without restarting NGINX.

APISIX achieves this by keeping a single NGINX server block with one location that forwards all traffic to the APISIX core, which dynamically selects the upstream based on the current etcd configuration.

Typical scenarios:

Add a new domain: create an upstream and a route in APISIX—no NGINX restart required.

Update IP blacklist via the

ip-restriction

plugin—changes propagate instantly.

Conclusion

NGINX’s traditional hot‑reload cannot meet the rapid change demands of modern cloud‑native and microservice architectures. Switching to a dynamic, in‑memory solution like Apache APISIX delivers zero‑downtime configuration updates, better resource utilization, and improved operational efficiency.