Article Details

Buy Tencent Cloud Account Setup High Availability Nginx Load Balancer on Tencent Cloud

Tencent Cloud2026-05-14 22:11:26MaxCloud

{ "description": "This article walks you through setting up a high availability Nginx load balancer on Tencent Cloud. You’ll learn how to plan a resilient architecture, choose regions and virtual machines, configure Nginx health checks, and integrate multiple balancers so failover doesn’t turn into a dramatic soap opera. We cover networking basics, security groups, load balancer design options, and practical Nginx configuration patterns. The guide also includes testing steps, monitoring tips, and troubleshooting advice, helping you avoid common “it works on my machine” surprises.", "content": "

So you want high availability (HA) for your Nginx load balancer on Tencent Cloud. Congrats! You’re about to upgrade from “please don’t crash” to “even if you crash, we’ll still keep serving customers.” In this guide, we’ll build a setup where multiple load balancer instances work together so that if one goes belly-up (power outage, kernel panic, dramatic cosmic events, you know), traffic can still flow to your backend services.

\n\n

Before we start: HA can mean different things depending on what you’re protecting and what you’re willing to spend. The approach here focuses on high availability at the Nginx tier and the network path to your backends. We’ll use multiple Nginx load balancer instances, configure them with health checks, and place them behind a Tencent Cloud networking component that can handle failover or distributing traffic. Along the way, we’ll keep everything readable, practical, and not overly magical.

\n\n

1. What “High Availability Nginx Load Balancer” Actually Means

In the simplest form, you’d run one Nginx instance that accepts incoming traffic and forwards it to your application servers. If that one Nginx instance fails, your service becomes a haunted house. High availability means you have a backup that takes over without manual heroics.

\n\n

There are two big layers to consider:

Load balancer HA: multiple Nginx instances exist, and traffic continues reaching healthy balancers if one fails.
Backend HA: your application servers are also redundant, and the balancer can route around unhealthy backends.

\n\n

This article primarily targets the load balancer tier. We’ll assume your backends already have redundancy, or at least we’ll configure Nginx to route based on health.

\n\n

2. Overview of the Architecture

Let’s sketch a common architecture that works nicely on Tencent Cloud:

\n\n

2.1 Typical HA Layout

You can set it up like this:

Two (or more) Nginx load balancer instances in the same VPC (often spread across at least two availability zones, if possible).
One frontend entry point that directs traffic to the healthy balancers. In many cases, Tencent Cloud’s load balancing service (or a similar traffic distributor) can do this health-based forwarding.
Multiple backend application instances that Nginx forwards to, with health checks so Nginx can skip failing backends.

\n\n

Think of it like a relay team:

Balancers are the runners receiving the baton (incoming traffic).
Backends are the team finishing the race (serving responses).
If a runner drops the baton (fails), the next runner grabs it immediately.

\n\n

2.2 Why Use Tencent Cloud Frontend Balancing

You could build HA entirely inside Nginx with VRRP/keepalived or distributed VIP solutions. That’s doable, but it adds complexity and more moving parts. Tencent Cloud already provides traffic management features designed for HA. We’ll leverage that so your solution stays maintainable and less “art project.”

\n\n

2.3 High Availability Goals

By the end, you want:

Incoming traffic should automatically move to another healthy Nginx balancer if the primary fails.
Nginx should route to healthy backends only.
Failure detection should be quick enough that users don’t notice (or at least don’t rage-quit).
Configuration should be repeatable and easy to update.

\n\n

3. Prerequisites and Planning

Let’s gather the essentials. You don’t need a wizard’s staff, but you do need a few practical details.

\n\n

3.1 Requirements

A Tencent Cloud account with permission to manage VPC networking, compute instances, and (if you use it) load balancing resources.
At least two compute instances for Nginx balancers.
At least two backend application instances (recommended).
Basic Linux knowledge: SSH, editing files, restarting services.
Firewall/security group access so traffic flows where it should.

\n\n

3.2 Choose Networking Mode

Most Tencent Cloud setups use a VPC. Decide whether you want internal-only balancing (within the VPC) or public entry (internet-facing). For many production setups, you’ll have an internet-facing front door that routes to internal balancer instances.

\n\n

Here’s the key: if your front door is public, lock down access to the balancer instances with security groups. If your entry is internal, still ensure only the front load balancer can talk to your Nginx instances.

\n\n

4. Create or Select Your Tencent Cloud Resources

We’ll describe the “what” at a conceptual level. Exact UI names and steps can vary, but the intent is the same. Follow your console prompts accordingly.

\n\n

4.1 Create Nginx Load Balancer Instances

Provision two instances, for example:

Buy Tencent Cloud Account lb-1 (Nginx #1)
lb-2 (Nginx #2)

\n\n

Best practice: place them in different availability zones if your setup allows it. You want your HA story to survive a zone-level problem, not just an individual VM faceplant.

\n\n

Make sure both instances:

Run the same OS family (or at least compatible package commands).
Have Nginx installed.
Buy Tencent Cloud Account Can reach the backend application instances on the required ports.
Are reachable by your frontend traffic distributor on the Nginx listening port (e.g., 80/443).

\n\n

4.2 Create Backend Instances

Provision at least two backend servers:

app-1
app-2
Optionally more

\n\n

Each backend should expose an application port (for example, 8080) and a health endpoint (like /health) that returns a 200 OK when the service is ready.

\n\n

4.3 Security Group Rules

Here’s a practical security posture:

Frontend traffic to Nginx: allow inbound traffic to lb-1 and lb-2 from the frontend load balancer (or from your expected source CIDRs).
Nginx to backends: allow inbound traffic to app-1/app-2 only from lb-1 and lb-2 (or from their private IPs/security group).
Admin access: restrict SSH/RDP to your admin IP ranges.

\n\n

Do not make everything open to the entire internet unless you enjoy living dangerously. Security is a feature, not a tax.

\n\n

5. Install Nginx on Both Load Balancers

Log into lb-1 and lb-2 and install Nginx. The exact commands depend on your OS. For Debian/Ubuntu it might look like:

\n\n

sudo apt-get update\nsudo apt-get install -y nginx\n

\n\n

For CentOS/RHEL-like systems:

\n\n

sudo yum install -y nginx\n

\n\n

Then enable and start:

\n\n

sudo systemctl enable nginx\nsudo systemctl start nginx\n

\n\n

If you’re running systemd, use systemctl. If your server is a surprise dinosaur with another init system, adapt accordingly. The rest of the configuration is the same idea.

\n\n

6. Configure Nginx for Backend Health and Load Balancing

Now for the fun part: making Nginx smart enough to route around unhealthy backends.

\n\n

Buy Tencent Cloud Account 6.1 Create a Simple Nginx Health Endpoint

Your frontend traffic distributor (the Tencent Cloud load balancer) will typically check whether each Nginx instance is healthy. That check should be fast and reliable. Nginx can serve a /nginx-health endpoint.

\n\n

On both lb-1 and lb-2, create or edit an Nginx configuration file. The default file path varies, but commonly it’s:

/etc/nginx/nginx.conf
/etc/nginx/conf.d/default.conf
/etc/nginx/sites-available/your-site

\n\n

Buy Tencent Cloud Account We’ll show a typical server block. Let’s assume Nginx listens on port 80.

\n\n

server {\n    listen 80;\n    server_name _;\n\n    # Frontend health check endpoint for the load balancer\n    location = /nginx-health {\n        access_log off;\n        add_header Content-Type text/plain;\n        return 200 'OK\\n';\n    }\n\n    # Main reverse proxy to backends\n    location / {\n        proxy_pass http://backend_pool;\n        proxy_set_header Host $host;\n        proxy_set_header X-Real-IP $remote_addr;\n        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n        proxy_set_header X-Forwarded-Proto $scheme;\n\n        # If you have long requests, you might want to tune timeouts\n        proxy_connect_timeout 3s;\n        proxy_send_timeout 30s;\n        proxy_read_timeout 30s;\n    }\n}\n

\n\n

The main missing piece is backend_pool, which we’ll define using an upstream section.

\n\n

6.2 Define an Upstream Pool With Health Checks (Nginx Plus vs OSS)

Nginx has multiple ways to do health checks. The most powerful health-check directives are in Nginx Plus. In open-source Nginx, active health checking is limited unless you add additional modules (or use passive health via failure detection).

\n\n

To keep this guide broadly useful, we’ll describe two approaches:

Approach A (common): Use fail_timeout and max_fails to handle unhealthy backends through passive checks.
Approach B (advanced): If you use Nginx Plus or a module that supports active health checks, add active checks for faster/cleaner detection.

\n\n

We’ll implement Approach A because it works with standard Nginx.

\n\n

6.3 Passive Health Handling With max_fails and fail_timeout

Add this upstream block (commonly in nginx.conf or a conf.d file):

\n\n

upstream backend_pool {\n    # Optional: keep it simple and let Nginx do round-robin\n    # You can choose least_conn as well.\n\n    server 10.0.1.10:8080 max_fails=3 fail_timeout=10s;\n    server 10.0.1.11:8080 max_fails=3 fail_timeout=10s;\n\n    # If you have a path-based routing or sticky sessions, we can adapt.\n}\n

\n\n

Replace:

10.0.1.10 and 10.0.1.11 with your backend private IPs
8080 with your application port

\n\n

What this does: if a backend fails repeatedly, Nginx temporarily stops sending traffic to it. Eventually it retries after fail_timeout. It’s not as elegant as active probes, but it’s reliable enough for many setups.

\n\n

6.4 Optional: Add a Backend-Specific Health Check Endpoint Through Nginx

If your backends expose /health, you might prefer active checks. But you can still expose a pass-through health endpoint for debugging or for a more advanced frontend check strategy.

\n\n

For example:

\n\n

location = /app-health {\n    proxy_pass http://backend_pool/health;\n    proxy_set_header Host $host;\n}\n

\n\n

However, remember: this doesn’t automatically make Nginx decide health. It just forwards the request.

\n\n

6.5 Validate and Reload Nginx

After you edit config:

\n\n

sudo nginx -t\nsudo systemctl reload nginx\n

\n\n

If nginx -t says “syntax is okay” (or otherwise), you’re good. If not, fix the error before reloading. Nginx is generally forgiving about configuration, but not about mistakes.

\n\n

7. Configure HA at the Front Door (Tencent Cloud Traffic Distributor)

This is the stage where traffic reaches your Nginx instances reliably. In many real-world designs, you’ll use Tencent Cloud’s Load Balancer services (Classic Load Balancer or Application Load Balancer, depending on your needs). The concept is: the frontend load balancer probes each Nginx instance’s health and sends traffic only to healthy targets.

\n\n

7.1 Create a Tencent Cloud Load Balancer (Conceptual Steps)

From the Tencent Cloud console:

Create a load balancer resource.
Choose the network (VPC or classic) based on your setup.
Set listeners (e.g., port 80 or 443).
Register targets: lb-1 and lb-2.
Configure health checks: use the endpoint /nginx-health on port 80 (or your Nginx port).

\n\n

7.2 Health Check Tuning

Buy Tencent Cloud Account Health check settings should balance quick detection with avoiding false positives. A reasonable starting point might be:

Buy Tencent Cloud Account Interval: 5s
Timeout: 2s
Healthy threshold: 2
Unhealthy threshold: 2 or 3

\n\n

If your /nginx-health always returns immediately, it should pass quickly. If it doesn’t, something is wrong (firewall, wrong port, Nginx not running, or your config never reloaded).

\n\n

7.3 Sticky Sessions (Usually Not Needed)

Load balancing is often stateless. If your application requires sessions stored in memory, you may need stickiness or session sharing (like Redis). For HA, external session storage is usually safer than relying on load balancer stickiness alone.

\n\n

8. Make the Two Nginx Balancers Identical (So Failover Doesn’t Create New Bugs)

Here’s a common HA failure mode: people configure lb-1 correctly, then copy the code to lb-2 incorrectly. Then when lb-1 fails, traffic goes to lb-2 and—surprise—everything breaks anyway. That’s not HA; that’s a plot twist.

\n\n

8.1 Use Configuration Management or a Simple Repeatable Process

At minimum, ensure both lb-1 and lb-2 have:

The same upstream backend_pool definitions.
The same /nginx-health location.
The same proxy_set_header and timeout settings.
Buy Tencent Cloud Account The same listen ports and firewall openness.

\n\n

If you can, use a script to deploy the config or use your favorite automation tool. Even a simple “scp config then reload” beats hand-editing at 2 AM.

\n\n

9. Handling TLS (HTTPS) With HA

If you’re serving HTTPS, you have a few options:

Terminate TLS at Tencent Cloud load balancer and forward HTTP to Nginx.
Pass-through TLS to Nginx (more complex).
Terminate TLS at Nginx on each balancer (and keep certs synced).

\n\n

The easiest HA path is usually to terminate TLS at the Tencent Cloud load balancer. Nginx then handles plain HTTP internally, and your certificates don’t need to be duplicated across multiple Nginx instances.

\n\n

If you choose to terminate TLS on Nginx, you must ensure both lb instances have the certificate and key configured identically and safely. Also handle renewals, which can be fun in the “we forgot and now we’re learning about expiry the hard way” sense.

\n\n

10. Testing Your HA Setup (Without Waiting for a Disaster)

Buy Tencent Cloud Account Let’s test. Testing is where you prove the HA story isn’t just a bedtime anecdote.

\n\n

10.1 Verify Nginx Health Endpoint

On lb-1 and lb-2, from a machine that can reach them:

Request http://lb-1-ip/nginx-health
Request http://lb-2-ip/nginx-health

\n\n

You should see “OK” with a 200 status.

\n\n

10.2 Verify Frontend Load Balancer Routes to Both

Send traffic through the frontend endpoint (the one created by Tencent Cloud load balancer). You can check which Nginx is responding by temporarily adding a header or by verifying a unique response.

\n\n

For example, you can add this temporarily in each Nginx instance:

\n\n

add_header X-LB-Instance "lb-1";\n

\n\n

And for lb-2:

\n\n

add_header X-LB-Instance "lb-2";\n

\n\n

Then observe which header you receive when you refresh. If you always hit lb-1, your load balancing distribution might not be configured as expected (or your algorithm may be stuck on one target).

\n\n

10.3 Simulate Nginx Failure on lb-1

Now the money test. On lb-1, stop Nginx:

\n\n

sudo systemctl stop nginx\n

\n\n

Within a short time (depending on your health check thresholds), the Tencent Cloud load balancer should mark lb-1 unhealthy and route traffic to lb-2.

\n\n

Confirm by:

Watching the frontend endpoint responses
Ensuring new requests are served from lb-2
Checking load balancer target health status

\n\n

Once you confirm it works, start Nginx again:

\n\n

sudo systemctl start nginx\nsudo systemctl reload nginx\n

\n\n

10.4 Simulate Backend Failure

Next, stop your backend app on app-1 (or block its port briefly). Then watch whether Nginx continues to route to app-2.

\n\n

With passive health handling, it might take a few failed attempts (because max_fails=3). That’s normal. HA isn’t magic; it’s statistical avoidance of bad targets.

\n\n

If you need faster failover at the backend level, you may consider active health checks (Nginx Plus or modules) or configure your load balancer to handle backend health.

\n\n

11. Monitoring and Observability (So You Know Before Your Users Do)

HA is great, but HA you can’t see is just expensive uncertainty. Add monitoring for:

\n\n

Nginx health: process running, request rates, upstream response codes.
Upstream health: how often Nginx marks a backend as failed.
Buy Tencent Cloud Account Frontend load balancer: target health status changes and health check failures.
Backend services: CPU, memory, error rates, and application logs.

\n\n

Practical Nginx logs help. Make sure you can access:

/var/log/nginx/access.log
/var/log/nginx/error.log

\n\n

If you use centralized logging, even better. When something breaks, you want a clear trail, not a scavenger hunt.

\n\n

12. Troubleshooting Common HA Problems

Let’s tackle the usual suspects. Most HA failures are embarrassingly human, like forgetting to open the right port or copying the wrong config file.

\n\n

12.1 Load Balancer Shows Both Targets Unhealthy

Check that Nginx is running on both lb instances.
Verify security group rules allow the load balancer health check to reach /nginx-health.
Confirm the health check path and port match your Nginx config.
Look at lb-1/lb-2 nginx error logs for startup or config issues.

\n\n

12.2 Traffic Only Goes to lb-1

Confirm both targets are marked healthy.
Check distribution algorithm settings (round-robin vs weighted vs stickiness).
Check whether your load balancer uses session stickiness you didn’t ask for.

\n\n

12.3 Failover Works, Then Traffic Breaks Anyway

Compare Nginx configs between lb-1 and lb-2.
Verify upstream backend_pool entries point to correct backend IPs and ports.
Make sure you reloaded Nginx after changes on both servers.
Confirm certificates (if terminating TLS on Nginx) exist on both balancers.

\n\n

12.4 Backends Become Unhealthy Slowly

With passive health via max_fails, detection is intentionally gradual. Increase fail_timeout or tune max_fails depending on your tolerance for transient errors.

\n\n

If you need faster backend switching, active health checks are the way to go.

\n\n

13. Production Hardening Tips (Because Life Is Messy)

Here are some upgrades that make your HA setup more robust:

\n\n

Use consistent upstream DNS vs IP: If backend IPs can change, prefer internal DNS names. If you use IPs, keep them updated.
Set sensible timeouts: Too low causes false failures; too high causes “slow death” when systems degrade.
Limit request sizes: Protect against accidental large uploads unless expected.
Enable keepalive to reduce connection overhead (usually beneficial).
Consider least_conn if your backends have uneven request durations.

\n\n

Example upstream tweak:

\n\n

upstream backend_pool {\n    least_conn;\n    server 10.0.1.10:8080 max_fails=3 fail_timeout=10s;\n    server 10.0.1.11:8080 max_fails=3 fail_timeout=10s;\n}\n

\n\n

14. Example Full Nginx Configuration (Copy-Friendly)

Below is a consolidated example you can adapt. Put it in a file under /etc/nginx/conf.d/ or modify your main nginx.conf accordingly.

\n\n

user  nginx;\nworker_processes  auto;\n\nevents {\n    worker_connections  1024;\n}\n\nhttp {\n    include       /etc/nginx/mime.types;\n    default_type  application/octet-stream;\n\n    upstream backend_pool {\n        # Choose one balancing strategy:\n        # round-robin is default; you can use least_conn if preferred.\n\n        server 10.0.1.10:8080 max_fails=3 fail_timeout=10s;\n        server 10.0.1.11:8080 max_fails=3 fail_timeout=10s;\n    }\n\n    server {\n        listen 80;\n        server_name _;\n\n        location = /nginx-health {\n            access_log off;\n            add_header Content-Type text/plain;\n            return 200 'OK\\n';\n        }\n\n        location / {\n            proxy_pass http://backend_pool;\n            proxy_http_version 1.1;\n\n            proxy_set_header Host $host;\n            proxy_set_header X-Real-IP $remote_addr;\n            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n            proxy_set_header X-Forwarded-Proto $scheme;\n\n            proxy_connect_timeout 3s;\n            proxy_send_timeout 30s;\n            proxy_read_timeout 30s;\n\n            # Optional: reduce issues with buffering for streaming apps\n            # proxy_buffering off;\n        }\n    }\n}\n

\n\n

Again, tune paths and placements to your OS and Nginx packaging. Nginx configs are like cats: they look similar until you find out which litter box they like.

\n\n

15. Final Checklist Before You Call It “Done”

Use this checklist so you don’t rely on vibes:

\n\n

lb-1 and lb-2 both run Nginx.
/nginx-health returns 200 on both.
Tencent Cloud load balancer health check is configured with the correct path and port.
Front door endpoint routes traffic to healthy balancers.
lb-1 and lb-2 share the same backend upstream configuration.
Backends respond on the application port.
When stopping lb-1, traffic continues through lb-2.
When stopping a backend, Nginx eventually routes away from it.
Logs and monitoring are in place to detect health changes quickly.

\n\n

16. A Note on Scaling Beyond Two Balancers

Two Nginx instances are a classic HA baseline. If you expect higher traffic or want better resilience, you can add more balancer instances. Just make sure:

You register all instances with the Tencent Cloud load balancer.
Health checks are configured consistently.
You keep Nginx configs identical across instances (or at least compatible).

\n\n

In other words: don’t just add more servers—add more confidence.

\n\n

Conclusion: Your HA Setup Is Now Less Haunted

Setting up high availability Nginx load balancing on Tencent Cloud isn’t just about clicking through a few console screens. It’s about designing the system so failures are expected, contained, and boring. That’s the goal: when something breaks, your service shouldn’t become a thrilling documentary titled “How to Lose Customers in Real Time.”

\n\n

You now have a roadmap and practical configuration patterns to deploy multiple Nginx load balancer instances, wire them into Tencent Cloud’s traffic management with health checks, and configure Nginx to route to healthy backends. Test it, monitor it, and tune it to your workload. Then sleep a little easier knowing that if one component fails, traffic can keep moving.

\n\n

If you want, tell me your backend protocol (HTTP or HTTPS), ports, and whether you’re using Nginx Plus or open-source Nginx. I can suggest the best health-check strategy and provide a refined configuration tailored to your exact scenario.

" }

上一篇Ready-made verified Alibaba Cloud account How to Protect Alibaba Cloud ECS with Cloud Firewall下一篇Huawei Cloud Third-party Payment Service Huawei Cloud ECS automated deployment script