Nginx reverse proxy setup: load balancing, SSL, WebSocket

Configuring Nginx reverse proxy: where responsiveness breaks

When all application traffic goes through a single entry node, the reverse proxy becomes a single point of entry and at the same time a single point of failure: if it is unavailable, all services are unavailable at once, including the admin panel and monitoring.

More often this is not hardware failure but a consequence of manual configuration edits: changes are made directly on the node, applied with a restart instead of a graceful reload — and this causes connection drops in the middle of a request. It goes unnoticed longest where long sessions are maintained: file uploads, chats, streaming.

The typical failure pattern looks like this: in the upstream block there is one address, without backup nodes and without retrying the request on a neighboring server on error. An application instance goes down — all traffic turns into errors, because there is nowhere to switch.

Nearby are redirects assembled with conditional blocks inside location, duplicated server blocks, certificates renewed manually and one day not renewed. In logs this appears as a burst of 5xx responses against a falling share of successful ones.

Configuring nginx reverse proxy begins with configuration ceasing to be manual: templates instead of edits on a live node, syntax validation before applying, graceful reload of workers with a wait timeout so that in-flight requests finish.

Then — several application servers behind one upstream name, retry to another node on error, separate health checks, TLS termination with automatic certificate renewal.

Long connections and WebSocket go along a separate route: their own idle timeouts, disabled buffering, forwarding of the Upgrade header. Without this, chat and streaming responses fall off after a minute of silence, although ordinary pages open normally.

We'll break down how this is closed: from the routing scheme and handling of node failures to automation of configuration rollout.

What a managed entry point provides: speed and resilience

A managed entry point is a single point where it is decided where a request will go.

A reverse proxy on nginx distributes them across an application pool taking node health into account: while a server responds within a specified threshold, it receives its share; when degraded, it is removed from rotation automatically.

A peak that previously brought the service down now produces an increase in response time by fractions of a second instead of access errors for some users.

Failure of an individual node ceases to be an incident.

Health checks with a configurable interval notice an unresponsive node within seconds, the unavailable instance is excluded, its requests go to the remaining ones, and a returning one is accepted into the pool only after readiness is confirmed.

The failure class "one machine out of five went down — half the pages don't open" disappears completely.

Traffic encryption is closed at the entry point: certificates are renewed automatically, outdated protocols are disabled, internal services communicate inside the perimeter without unnecessary cryptography costs.

Manual work with certificate issuance and the typical outage "we let it expire — the site is unavailable" goes away.

The effect is measured in numbers: the share of requests served without manual intervention approaches one, response time under peak remains predictable, and static caching and response compression reduce load on applications. Below — how this is assembled in practice.

Balancing schemes: options, limitations, nuances

A single entry node with Nginx — the simplest scheme and at the same time the most fragile: a planned configuration update or process restart stops all external traffic, along with encryption termination and open WebSocket sessions. While the node is alone, any edit to the entry configuration is a downtime window.

The choice between schemes is determined by three questions: whether the application stores session state, how many entry points the environment is prepared to maintain, and whether there is a managed balancer at the perimeter.

The scheme is chosen not by "correctness" but by the acceptable failure class. In a clustered environment, Nginx is usually left at the application level — routing, cache, rate limiting — while traffic distribution is delegated to the external level.

Implementation order: from traffic audit to handover

The order of work is structured so that each next step relies on data from the previous one, not on assumptions. We never start by editing configs: first we need to understand what traffic will go through the proxy and what exactly is breaking now.

Below — the sequence by which implementation proceeds predictably, while preserving the ability to roll back at any step.

1. Traffic audit. We take a map: domains and subdomains, request shares by type, connection duration, volume of long-lived WebSocket sessions, peak windows. Separately we record where TLS is currently terminated and where DNS points — this determines the switching scheme.
2. Scheme design. We determine certificate termination points, upstream server sets, balancing policy, timeouts for long connections, and header processing order. We agree on the scheme with your team before the first configuration edit.
3. Configuration in a test environment. We assemble the configuration block by block and validate syntax before applying. We stand up a copy of the scheme on a separate staging environment to catch errors without affecting production requests.
4. Testing under load. We apply a profile close to production, including WebSocket and slow application responses. We watch how latency grows, whether connections hold when one server fails, and how long switching takes.
5. Switching without downtime. We move traffic gradually: first a portion of requests, then the full volume. The old scheme remains operational and ready for rollback until new metrics confirm stability.
6. Handover to operations. We hand over configurations in repositories, the connection scheme, certificate renewal policies, dashboards and alert rules, and rollback instructions. We conduct a walkthrough with the on-call team so that typical failures are resolved without us.

Configurations, routing schemes and access policies

Setting up a reverse proxy does not end with a working config on the production node.

We hand over to the customer's team a set of artifacts by which the infrastructure can be reproduced, developed, and handed over to another engineer — without figuring out "magic" directly on the server and without reading chat history.

• Configurations in a version control system — split by meaning: global parameters, upstream descriptions, a separate block for each domain. Changes go through review and are first rolled out to staging.
• Routing scheme — the path of a request from the entry point to a specific service: which domains and paths are proxied where, where TLS is terminated, under what conditions traffic goes to a backup upstream.
• Access policies — restrictions by addresses and subnets for administrative zones, authentication rules, explicit separation of public and internal routes.
• Connection and timeout limits — maximum number of simultaneous connections per node and per client, buffer sizes, upstream response wait time, thresholds for protection against traffic bursts.
• Rules for WebSocket and long-lived connections — correct protocol switching headers, a separate upstream without buffering, increased timeouts for such routes.
• Maintenance regulations — the procedure for certificate renewal, log rotation, configuration reload without breaking active connections, and rollback to the previous version.
• Monitoring map — which metrics are collected from the proxy, which values are considered critical, where notifications go, and who handles them.

Each item is checked on staging before traffic is moved, so after launch the team has not a configured server but a managed scheme with clear change points.

Case study: how downtime during release rollouts was eliminated

Before the redesign, a release was rolled out by restarting the only node: each deployment caused 4–6 minutes of full unavailability, and the window for it was chosen at night to fit within minimum traffic.

A node failure meant downtime until the on-call engineer arrived — recovery took tens of minutes and kept the whole team engaged.

The application and the entry point were separated: in front of the service appeared a reverse proxy layer on Nginx with a group of three nodes.

Static content and secure connection termination were left on the proxy, dynamic content is served by the nodes, and chat connections go through the same layer with forwarding of protocol upgrade headers — deployment no longer breaks users' open sessions.

Metrics before and after

Availability checks were moved into the proxy: if a node does not respond for two cycles, traffic goes to live ones, and a returned one accepts load again. We update rules and certificates with a soft reload, so edits do not break active connections.

Planned maintenance on one node now goes unnoticed by users, and a release is no longer an event to prepare for in advance.

How does a reverse proxy differ from a balancer?

Strictly speaking, these are not two different tools but two roles of one entry node. A reverse proxy is the entry point: it alone accepts the connection from the client and redirects it to the application.

A balancer is a special case of the same role, when there is more than one application and a choice must be made about which one should receive a specific request.

The reverse proxy is responsible for everything that happens before routing: terminates TLS and renews certificates, inserts Host and X-Forwarded-* headers, limits body size and request rate, compresses responses, caches static content, passes Upgrade through for WebSocket. This is entry management, not distribution.

Balancing begins where an upstream with several servers appears in the configuration: selection algorithm (round robin, by number of active connections, IP binding), health checks, removal of a failed node from rotation, retry of a request on a neighboring server, session persistence. Without this list, the word "balancing" means nothing — just a hostname remains.

In Nginx, both roles live in one config: the upstream block connects to server, and the same node that terminated TLS begins distributing traffic.

Therefore the question is not "proxy or balancer" but how many application instances you have and whether they need a common entry point.

If there is one instance, adding distribution is pointless — TLS, WebSocket, limits, and a single place for routes remain. If there are several or a smooth rollout without downtime is needed, checks, node removal from rotation, and session persistence are added as well. Next we break down how this is assembled for a specific scheme.

Certificates, long-lived connections and limits: concerns

Before launch, customers ask the same questions: what will happen when the certificate expires, will the proxy handle long-lived connections, and will the administrative interface be exposed externally. Below — short answers, while details are covered during the configuration design stage.

How will WebSockets behave behind a reverse proxy?

A long-lived connection requires explicit protocol switching headers and an increased wait time — otherwise the channel drops on silence. We move WebSockets into a separate routing block and select timeouts for the real traffic profile.

What about limits on the number of simultaneous connections?

We calculate limits based on the number of simultaneous clients and reserve for bursts, not "by eye," and limit the request rate from a single address. Under peak load, the queue does not grow, and regular users do not see failures.

Do administrative ports and control panels remain open?

No. The panel and metrics listen only on the local address; only a single entry point faces outward. Administrative sections are closed by an allowlist of addresses and separate authentication; everything else is filtered by the firewall.

Let's discuss your scheme and get back with an estimate

To get back with an estimate and work plan rather than clarifying questions, we need several inputs about the current scheme. Below — what most often removes uncertainty in projects where nginx is already in front of the application or is only planned as the entry point.

• List of domains and subdomains that will go through the proxy, and where TLS is currently terminated: on nginx itself, on a balancer above, or inside the application.
• Backend pool: service addresses and ports, their number, and the preferred load distribution method — round robin, by number of active connections, with client-to-server binding.
• Requirements for long connections: whether WebSocket, response streaming, events are needed, and what connection drop is considered unacceptable.
• Fault-tolerance scheme: one node, a pair with a floating address, or several behind an external balancer; whether graceful configuration restart without breaking active requests is needed.
• Certificates and their issuance procedure: external or internal center, auto-renewal, one shared or separate for each domain.
• Observability: where access and error logs are written, which metrics are collected, whether there is a log collector, and what thresholds alerts are configured for.
• Limitations and access: allowed networks, request rate limiting, burst protection, who issues access to servers and changes configuration.

Next — estimate and work plan: we break implementation into stages from configuration preparation and staging validation to traffic switching and handover to operations, and for each stage we record the timeline and responsible person on both sides.

Post-launch support is a separate item — certificate renewal, configuration rotation, incident on-call.

Describe the task and attach current configurations with the network scheme, if available — we'll discuss them and get back with an estimate and plan.