Tencent Cloud CVM How to deploy Nodejs application on Tencent Cloud server with reverse proxy

You’re probably searching because you want to get a Node.js app online quickly on Tencent Cloud—without getting stuck at account verification, payment, or risk-control checks, and without spending days on reverse proxy troubleshooting (Nginx/HTTPS/timeouts/headers/WAF).

What you actually need to decide first (before touching reverse proxy)

In practice, most delays come from deployment prerequisites—especially if you’re new to Tencent Cloud or switching payment methods. Before you deploy, confirm these five items:

1. Which compute type you’ll use: CVM (cloud virtual machine) is the typical path for reverse proxy + Node.js. If you plan to add SSL, consider whether you’ll terminate at Nginx or at a Tencent load balancer.
2. Your KYC/verification status: some users can provision instances immediately, but fail later during IP/SSL/WAF-related configuration or enterprise verification. If your goal includes external exposure, verify early.
3. Where your app listens: decide the internal port (e.g., 127.0.0.1:3000). Reverse proxy should not hit public ports unless you intentionally expose them.
4. How you’ll manage process: systemd or pm2? A common mistake is starting Node manually and forgetting it won’t survive reboots.
5. Payment method constraints: depending on your region and identity status, top-ups and auto-renew behavior can differ. That affects how you handle monthly/annual billing for IPs, bandwidth, and certificates.

Cloud account purchasing & activation checklist (so you don’t hit a wall mid-deploy)

Here’s the sequence I recommend based on operational experience: users often provision a VM, deploy the app, then discover later they can’t finalize outbound networking settings, renewability, or some security products.

1) Complete identity verification (KYC) before you pay for external exposure

Tencent Cloud generally requires some level of identity verification (and sometimes enterprise verification) to avoid risk-control friction when you:

• bind or reuse public IPs
• enable certain security products
• set up HTTPS/cert-related operations
• purchase long-term resources (auto-renew / renewal)

Common failure causes I see:

• Name mismatch between account holder and document (especially for enterprise accounts where legal entity name differs).
• Document type unsupported for your account category/region.
• Network/VPN inconsistency during verification (some users try to verify from changing regions; it triggers risk flags).

2) Choose “pay-as-you-go” vs monthly subscription carefully

Tencent Cloud CVM If you’re testing reverse proxy and don’t know load patterns yet, pay-as-you-go reduces commitment. But if you plan to keep it running for months and need stability, monthly/subscription can reduce admin overhead.

Operational tip: Even when you’re using pay-as-you-go for the CVM, you might still need to manage bandwidth and public IP charges separately. If funding lapses, services can stop or become unstable—then reverse proxy appears “broken” even though it’s really an upstream connectivity or resource deactivation issue.

3) Budget for “renewal reality”

Tencent Cloud CVM People underestimate renewal. Certificates, elastic public IP, and some security toggles can have independent billing cycles. Before you set up Nginx for HTTPS, check whether certificate issuance/renewal requires additional account standing.

Payment methods & how they affect deployment workflow

Tencent Cloud International billing can use different payment paths depending on your region, verification level, and resource type. The practical impact is usually timing (when funds must be available) and whether your renewal can auto-complete.

What to watch

• Prepaid / top-up style: if you top up manually, ensure you have enough balance for both compute and bandwidth/IP. Otherwise Nginx may continue running but the instance/network becomes unreachable.
• Tencent Cloud CVM Auto-renew / subscription: convenient, but if your verification status changes or the account flags risk, renewal can fail and lead to downtime.
• Enterprise verification timing: for companies, the “enterprise verification completed” timestamp can determine whether certain purchases are allowed immediately.

Recommendation: When deploying your first Node.js service, I usually advise enabling the minimum required components (CVM + security group + public IP + bandwidth). Add HTTPS/cert and WAF after the core reverse proxy works.

Reverse proxy deployment: a deployment plan that avoids the usual traps

Assume you have a Node.js app (Express/Nest/Fastify—doesn’t matter) running on port 3000. You want Nginx to handle incoming traffic and forward to Node via localhost. The goal: predictable headers, stable keep-alives, clean logs, and no accidental exposure of the Node port.

Step 1: Provision CVM + open only what you must

• OS: Ubuntu 22.04 (or similar)
• Security group inbound rules:
  • TCP 80 from your office/IP range or any (if public)
  • TCP 443 if you’ll enable HTTPS later
  • Do NOT expose TCP 3000 publicly

Why this matters: If you expose TCP 3000, you’ll often see it in logs as direct hits or bots hitting your app. Even if Nginx is “in front,” you’ll lose control over rate limiting and headers.

Step 2: Install and configure Nginx

On the instance:

sudo apt-get update
sudo apt-get install -y nginx

Example reverse proxy config for example.com:

sudo nano /etc/nginx/sites-available/nodeapp

server {
    listen 80;
    server_name example.com;

    # Logging (helps when debugging upstream issues)
    access_log /var/log/nginx/nodeapp_access.log;
    error_log  /var/log/nginx/nodeapp_error.log;

    # If your Node runs behind a sub-path, you must adjust proxy_pass.
    location / {
        proxy_pass http://127.0.0.1:3000;

        # WebSocket support (common Node requirement)
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Preserve client identity for app-level logic
        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;

        # Avoid 502/504 during slow upstream startups
        proxy_connect_timeout 5s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;

        # Prevent buffering issues on streaming responses
        proxy_buffering off;
    }
}

Enable the site and reload:

sudo ln -s /etc/nginx/sites-available/nodeapp /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Step 3: Run Node.js reliably (systemd or pm2)

If you rely on manual node server.js, reboots and deployments will break unexpectedly. Here’s a systemd example (more predictable for production).

sudo nano /etc/systemd/system/nodeapp.service

[Unit]
Description=Node.js App
After=network.target

[Service]
Environment=NODE_ENV=production
WorkingDirectory=/opt/nodeapp
ExecStart=/usr/bin/node /opt/nodeapp/server.js
Restart=always
RestartSec=3

# If your app binds to 127.0.0.1:3000 only, it’s safer.
# (No need for additional firewall rules beyond Nginx access.)
User=www-data
Group=www-data

# Logs to journal
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Enable and start:

sudo systemctl daemon-reload
sudo systemctl enable nodeapp
sudo systemctl start nodeapp
sudo systemctl status nodeapp

Step 4: Validate the full chain (Nginx → Node → app health)

Before mapping DNS/HTTPS, test locally:

curl -I http://127.0.0.1:3000/health
curl -I http://127.0.0.1/

Then test from outside using the instance’s public IP:

curl -I http://<public-ip>/

Common Nginx errors you should expect:

• 502 Bad Gateway: Node not running, listening on wrong port, or binding to a different interface.
• 504 Gateway Timeout: upstream is slow; increase proxy_read_timeout or fix app performance.
• WebSocket not working: missing Upgrade/Connection headers in config.

HTTPS on Tencent Cloud: deploy in the right order to avoid certificate/risk issues

Many users jump to HTTPS first, then lose time on validation steps or account standing problems. My recommended order is:

1. Make Nginx reverse proxy work on port 80
2. Confirm DNS and inbound rules
3. Enable HTTPS (certificate install / managed certificate)

For HTTPS, you’ll typically adjust Nginx to listen 443 and redirect HTTP→HTTPS after certificate is ready. Use server_name matching your domain exactly.

Risk-control angle: If your account identity verification is incomplete or flagged, some certificate management operations may be limited. It can also cause delays in domain validation workflows. If you’re seeing inexplicable “permission denied” or resource operation failures, check your account verification status first rather than re-editing Nginx.

Scenario-based fixes (real-world problems users hit when deploying Node behind Nginx)

Scenario A: You can’t reach the site from the internet (but Nginx looks fine)

Symptoms: curl http://127.0.0.1 works on the server, but public traffic fails.

Checklist:

• Security group inbound allows TCP 80/443 to the instance
• Public IP is attached to the correct CVM
• OS firewall (UFW/iptables) not blocking ports
• DNS points to the correct IP
• No “maintenance” state due to billing lapse (instance/network unreachable)

Tencent Cloud CVM Scenario B: 502/504 after you “fixed” the config

Nginx might be forwarding to the wrong upstream. Common causes:

• Node listens on 0.0.0.0:3000 vs 127.0.0.1:3000 mismatch with proxy pass
• App crashed and systemd didn’t restart (check systemctl status)
• Port already used or app bound to different port (e.g., 3100)

Actionable approach:

# See if Node is listening
sudo ss -lntp | grep 3000

# Follow Nginx error log
sudo tail -n 200 /var/log/nginx/nodeapp_error.log

Scenario C: Your app works locally but fails behind Nginx due to URL generation

Symptoms: assets load incorrectly, redirects loop, or OAuth callback URLs break. Fix usually involves correct forwarded headers.

• Make sure you set X-Forwarded-Proto and Host
• In your app, configure trust proxy (for Express) or use appropriate setting for your framework

For Express, for example:

app.set('trust proxy', true);

Cost comparisons you should do before going live

Reverse proxy itself is “cheap,” but your exposure costs (public IP, bandwidth, and optional load balancer/WAF) are what surprise teams. Below is a practical way to think about cost in your first month.

Cost drivers (usually unavoidable)

• CVM compute: depends on CPU/memory size you pick.
• Bandwidth: egress traffic (especially if your app serves static assets or media).
• Public IP: if you use/keep an elastic IP, it may have separate charges.

Optional drivers (choose after proof of concept)

• WAF / security services: protects public endpoints but adds cost and can create false positives if misconfigured.
• Managed certificate or additional HTTPS automation features.
• Load balancer instead of “direct public IP + Nginx”.

Pragmatic approach I use: deploy with direct public IP + Nginx first, measure real request volume and latency, then decide whether a load balancer/WAF is worth the margin. This avoids overpaying on day one and helps you keep reverse proxy stable before adding complexity.

Account usage restrictions & compliance checks that can impact deployment

Even if your technical setup is correct, Tencent Cloud account restrictions can block or degrade your deployment. Based on typical operational patterns, watch for:

• Resource provisioning restrictions: new accounts sometimes can’t purchase certain services until verification completes.
• Instance/network interruptions: if billing is insufficient or auto-renew fails, public reachability breaks.
• Tencent Cloud CVM WAF/security policy limitations: certain rules require enterprise verification or domain ownership checks.

If you’re operating in a jurisdiction requiring special hosting compliance (or your content triggers stricter review), align verification and deployment timing. Don’t schedule a critical release before those checks finish.

Frequently asked questions (the questions people ask right before they deploy)

Tencent Cloud CVM 1) Do I need to expose my Node port (3000) publicly?

No. Keep Node bound to 127.0.0.1 and let Nginx be the only public entry. This reduces your attack surface and makes debugging easier because all external traffic should go through one point.

2) Why do I keep seeing “connection reset by peer” from Nginx?

Usually upstream is crashing or refusing connections. Check:

• systemctl status nodeapp
• Node logs in journal: sudo journalctl -u nodeapp -n 200 --no-pager
• Tencent Cloud CVM Nginx error log

3) My WebSocket app works on dev but not production—what’s missing?

Add the Upgrade/Connection headers in Nginx and keep proxy_http_version 1.1. Also ensure your Node server isn’t behind a path rewrite that breaks the WS handshake.

4) How do payment and renewal affect my availability?

If funds run out or renewal fails, public endpoints can become unreachable. Reverse proxy may still appear “configured,” but upstream connectivity will fail due to deactivated resources or network.

5) What if reverse proxy is fine but HTTPS fails after I request a certificate?

Common culprits:

• Nginx server_name doesn’t match the domain
• Port 80/443 inbound rules aren’t correctly configured for validation
• Account verification isn’t complete, blocking certificate issuance/renewal steps

Deployment runbook (quick start you can follow)

1. Verify Tencent Cloud account KYC status; avoid starting HTTPS/cert steps before it’s complete.
2. Create CVM; attach/enable public IP; open inbound TCP 80 (and 443 later).
3. Tencent Cloud CVM Install Nginx; configure proxy_pass http://127.0.0.1:3000 + headers (Host/X-Forwarded-For/X-Forwarded-Proto).
4. Deploy Node app with systemd or pm2; verify curl http://127.0.0.1:3000/health.
5. Reload Nginx; verify curl http://127.0.0.1 and then from outside via public IP.
6. Only after 80 works, set up HTTPS and redirect HTTP→HTTPS.
7. Set monitoring/log review: Nginx error log + Node journal logs to catch 502/504 quickly.

If you tell me 4 details, I can tailor the exact Nginx + Node config

Reply with:

• Your Node framework (Express/Nest/Fastify/Next.js API/etc.)
• App listening port & address (e.g., 3000 on 127.0.0.1 or 0.0.0.0)
• Domain + whether you need WebSocket
• Whether you want HTTP only at first or HTTPS from day 1

I’ll provide a production-ready Nginx config (including timeouts, WebSocket headers, buffering choices, and HTTPS redirect rules) and the safest approach for your Tencent Cloud account/payment situation.