PowerCloud PowerCloud Contact Us

Huawei Cloud Global Edition How to configure Nginx on Huawei Cloud Japan server

Huawei Cloud / 2026-07-17 16:34:37

Quick answer first: what you can do on a Huawei Cloud Japan (Tokyo) server with Nginx

If your real goal is “I bought/activated a Huawei Cloud Japan server and I want Nginx online today,” you usually need two tracks at once:

  • Track A — Access + security + OS readiness: make sure the instance is reachable (SSH), ports 80/443 are allowed, and your Linux firewall/security group won’t block incoming traffic.
  • Track B — Nginx deployment: install Nginx, configure site(s), validate config, enable start on boot, and set up reverse proxy + TLS if you’re serving HTTPS.

This guide is written for that real path: after account purchase/activation, you hit “ops friction” (KYC, payments, security group, renewal, restrictions). Then you do Nginx deployment without getting stuck.

Before you configure Nginx: the purchase/activation steps that actually block you

People search this topic because they’re already holding an instance—but on Huawei Cloud Japan, account and risk control steps can delay network access or instance creation. Here’s what matters operationally.

Huawei Cloud Global Edition 1) What you must have ready after buying a Huawei Cloud Japan ECS instance

  • Huawei Cloud Global Edition Huawei Cloud account status = “active”: if your account is still in verification or risk review, you may create resources but later encounter provisioning delays or restricted actions.
  • Identity verification completed (KYC): even for basic web hosting, KYC failures can cause payment/refund loops and renewal issues later.
  • Payment method confirmed: some payment methods work smoothly on first payment but fail on renewal due to bank risk checks.

2) Common KYC failure reasons (so you don’t waste a week)

From real account operations, the most time-consuming problems are identity matching and document quality:

  • Document blur / glare / shadow → automated OCR fails; you’ll get “image not clear” responses.
  • Huawei Cloud Global Edition Name mismatch between registration name and ID text (even spacing differences). Use exactly the same transliteration/case policy if your platform asks.
  • Wrong document type (e.g., using a residence permit photo when the form expects national ID or passport).
  • Huawei Cloud Global Edition Selfie mismatch if a “liveness check” is required; lighting and angle matter.
  • Submitting from a “risky” network (VPN/proxy sometimes triggers risk scoring). If you’ve been rejected once, try from a stable home/office network.

Actionable tip: If your KYC status is “in review,” don’t keep retrying the same submission daily. Wait; repeated submissions can trigger additional risk control and prolong approval.

3) Funding + renewal: the payment method difference you feel during operations

Huawei Cloud Japan is usually set up so that:

  • Pay-as-you-go charges automatically at the end of billing cycles.
  • Monthly/annual subscriptions often require a valid payment source to renew without interruption.

In practice, renewal failures often come from:

  • Credit card “3D secure” / bank risk lock during renewal even if initial payment succeeded.
  • Insufficient balance / expired card on the payment method stored in the account.
  • Payment source mismatch with billing region (e.g., card issued in a country inconsistent with billing settings).

Practical advice: For production hosting, prefer a payment method with stable renewals for the next 3–6 months (not “just for the first month”). If you’re testing Nginx, pay-as-you-go reduces the damage if you need to rebuild the instance.

Security checklist before you touch Nginx (so you don’t think Nginx is broken)

Huawei Cloud Global Edition When someone says “Nginx is running but I can’t access it,” 80% of the time it’s networking, not configuration.

1) Confirm Security Group / Firewall allows 80/443

  • Open TCP 22 for SSH from your IP (don’t open SSH to 0.0.0.0/0 if you can avoid it).
  • Open TCP 80 and/or TCP 443 to your desired source (IP range or CDN/WAF IPs if you have them).

Huawei Cloud Global Edition Real-world failure mode: People add Nginx server blocks for 80/443, restart Nginx, but forgot the inbound rule at the cloud security group layer. Browser still times out.

2) Validate the instance has a public IP (or use a Bastion/VPN)

If you only have a private network interface, you’ll need a jump host or VPN tunnel to SSH. Nginx setup won’t matter until you can reach the box.

3) Check your OS image and package manager

Different Huawei Cloud ECS images can be CentOS/Alma/Rocky/Ubuntu/Debian. Before running commands, confirm:

cat /etc/os-release

Install Nginx on Huawei Cloud Japan server (step-by-step you can run)

Below are common paths by distro. Pick the section matching your OS.

Ubuntu / Debian

sudo apt update
sudo apt install -y nginx
sudo systemctl enable --now nginx
sudo nginx -t

CentOS / Rocky / AlmaLinux

sudo yum install -y nginx
sudo systemctl enable --now nginx
sudo nginx -t

Operational note: If you use a minimal image, Nginx might not exist in the base repos. In that case, install via your image’s default repo or enable required repos (but don’t blindly pull external mirrors unless you understand the security impact).

Confirm listening ports (don’t rely on “systemctl status” alone)

sudo ss -lntp | grep -E ':80|:443'

If you see no listeners, your Nginx config likely isn’t loaded or the service failed earlier—run:

sudo systemctl status nginx --no-pager
sudo journalctl -u nginx -n 100 --no-pager

Configure Nginx for your domain (reverse proxy + static hosting)

Most users using Nginx on cloud are not doing “hello world.” They want either:

  • Reverse proxy to an app (Node/Java/Python, etc.)
  • Static site hosting (Vue/React built files)

Option A: Static site hosting (Vue/React build folder)

Example: serve /var/www/site as your web root.

sudo mkdir -p /var/www/site
sudo chown -R $USER:$USER /var/www/site

Upload your built files into /var/www/site, then edit:

sudo nano /etc/nginx/sites-available/site.conf

Ubuntu/Debian style config (adjust paths to match):

server {
    listen 80;
    server_name example.com;

    root /var/www/site;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
    }
}

Enable it (Ubuntu/Debian):

sudo ln -s /etc/nginx/sites-available/site.conf /etc/nginx/sites-enabled/site.conf
sudo nginx -t
sudo systemctl reload nginx

Option B: Reverse proxy to an application on localhost

Example target: app listening on 127.0.0.1:3000.

sudo nano /etc/nginx/conf.d/app.conf

upstream app_upstream {
    server 127.0.0.1:3000;
    keepalive 32;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://app_upstream;
        proxy_http_version 1.1;

        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;

        proxy_connect_timeout 5s;
        proxy_send_timeout 30s;
        proxy_read_timeout 30s;

        # WebSocket support (commonly forgotten)
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Reload safely:

sudo nginx -t
sudo systemctl reload nginx

Common ops mistake: You proxy to localhost:3000 but your app is bound to 0.0.0.0 only (or only to IPv6). Fix your app binding (usually 127.0.0.1), then reload Nginx.

HTTPS on Huawei Cloud Japan: TLS setup that doesn’t cause downtime

You can terminate TLS at Nginx, typically with Let’s Encrypt or your own certificate. The tricky parts are port 80 routing, certificate renewal permissions, and firewall rules.

Let’s Encrypt (fast path)

Ensure port 80 is reachable from the public internet before you request certificates. For example:

  • Security group inbound includes TCP 80
  • Nginx can serve /.well-known/acme-challenge/ or you use certbot’s webroot method

If you’re using certbot with Debian/Ubuntu:

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Then verify:

sudo nginx -t
sudo systemctl reload nginx

Renewal that doesn’t break your next month

Check the renewal timer:

sudo systemctl list-timers | grep certbot

If it’s not scheduled, enable it. Also, ensure your server clock is correct (TLS validation can fail if time drift is large).

Real-world downtime story: A customer opened only TCP 443, but their Let’s Encrypt HTTP-01 challenge required port 80. Certificate issuance failed; they had to temporarily open port 80 and re-run the issuance/renewal.

“Nginx is configured, but I still can’t access it” — troubleshooting flow

Use this order. It reduces time-to-fix compared to random editing.

Step 1: Local test from the server

curl -I http://127.0.0.1
curl -I http://localhost
  • Huawei Cloud Global Edition If local curl works but external doesn’t → network/security group/route/DNS.
  • If local curl fails → Nginx config, upstream service down, or binding issues.

Step 2: Check Nginx config syntax and included files

sudo nginx -t
sudo ls -la /etc/nginx/

On some images, configs are split across conf.d, sites-enabled, or nginx.conf includes. A file existing doesn’t mean Nginx loads it.

Step 3: Validate upstream/app health

sudo ss -lntp | grep 3000

If your upstream app isn’t listening, Nginx might still show as “running” but returns 502/504 to clients.

Step 4: External connectivity from your workstation

curl -I http://YOUR_PUBLIC_IP

If IP works but domain fails → DNS record or domain mapping. If IP fails → security group, public routing, or IP not attached.

Step 5: Review Nginx logs

sudo tail -n 200 /var/log/nginx/error.log
sudo tail -n 200 /var/log/nginx/access.log

Account usage restrictions that affect server operations (what to watch)

This is the part people ignore until the problem becomes urgent: some account/risk control policies can lead to throttling, restrictions on resource creation, or termination if payments fail.

1) If your payment renewal fails, what happens to your instance?

Usually you’ll see one of these operational consequences:

  • Instance enters a locked/limited state
  • Billing continues until a cutoff, then resources stop
  • Related resources (EIP/ELB/traffic) might behave differently than the ECS itself

Practical mitigation: Before going live, check billing dashboard for upcoming renewals and confirm the payment instrument is still valid.

2) Risk control reviews and “too many changes” events

If you frequently create/destroy instances, or automate key actions from unusual geolocations/IPs, risk control might flag the account. That can slow provisioning or block new resources temporarily.

Mitigation I recommend: Keep a stable admin access pattern (VPN/IP consistency), and avoid “create 20 instances then delete within 10 minutes” during testing unless you’re sure you won’t trigger enforcement.

3) Region and service constraints

For Japan, ensure your domain, DNS, and any CDN/WAF are aligned. Mismatched configurations often look like Nginx misconfig but are actually edge routing issues.

Cost comparison: how Nginx hosting costs typically break down on Huawei Cloud Japan

You don’t just pay for “Nginx.” The costs that matter are usually:

  • ECS instance hourly/monthly
  • Public bandwidth / traffic
  • Optional Elastic IP / Load Balancer / WAF/CDN
  • Certificate tooling (Let’s Encrypt is free; your own automation may cost your engineering time)

Scenario-based cost planning

Scenario Typical setup What drives cost What to watch
Personal site / demo ECS + Nginx static ECS uptime + low traffic Don’t over-provision CPU/RAM
Small web app (reverse proxy) ECS + Nginx proxy to app App resources + traffic Increase timeouts carefully (502/504)
Traffic spikes ECS + LB/WAF/CDN + Nginx Load balancing + egress Rate limiting & log volume

Actionable tip: If you’re deciding between “ECS-only with Nginx” and “add a LB/CDN,” start with ECS-only for validation. Move to LB/CDN only after you can measure real concurrent connections and peak bandwidth from access logs.

Huawei Cloud Global Edition Frequently asked questions (the ones that match real search behavior)

Q1: Do I need Huawei Cloud Japan KYC to configure Nginx?

To configure Nginx on an already provisioned instance, no. But to buy/activate and keep services running reliably, yes. If your KYC/payment status is not stable, you’ll risk instance creation interruptions or renewal failures that will take your web service down.

Q2: What payment method differences matter for a hosted website?

Operationally, the big difference is renewal stability. If you select a payment instrument that sometimes requires bank approval on recurring charges, your website can fail around the renewal date. Pay-as-you-go is safer for short experiments; monthly/annual subscriptions are fine once KYC and payment instrument stability are confirmed.

Q3: Nginx shows 200 locally but browser gets 502/504—why?

That usually means your upstream app is not reachable from Nginx (app not running, wrong port, binding to wrong interface, or firewall inside the instance). Check:

  • sudo ss -lntp | grep <upstream_port>
  • Nginx error log: tail -n 200 /var/log/nginx/error.log

Q4: How do I handle IPv6 issues on a Huawei Cloud Japan instance?

Some images enable IPv6 and Nginx may resolve localhost to ::1. Fix by using explicit 127.0.0.1 in upstream or setting listen [::]:80;/listen 80; deliberately. Also check curl -6 vs curl -4.

Q5: Can I use Nginx without opening port 80?

Yes for “internal-only” setups. But for Let’s Encrypt HTTP-01 issuance/renewal, you need port 80 reachable (unless you use DNS-01 or TLS-ALPN-01). For production, it’s common to allow port 80 and redirect to HTTPS.

Q6: What if my instance firewall blocks traffic even after security group changes?

Some images ship with UFW or firewalld active. Verify and adjust local rules. Example for firewalld:

sudo firewall-cmd --list-all
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

Q7: Why does my Nginx config change not take effect?

Common causes:

  • You edited the wrong file (e.g., edited conf.d but your distro uses sites-enabled).
  • You ran restart without errors, but Nginx loaded an older include path.
  • nginx -t passed but the server block isn’t selected (wrong server_name).

Do: run nginx -T to dump the full config and confirm includes.

Two practical “ready-to-use” command bundles

Bundle 1: Minimal Nginx deployment (Ubuntu/Debian)

sudo apt update
sudo apt install -y nginx
sudo systemctl enable --now nginx
sudo nginx -t

Bundle 2: Reverse proxy template with safe reload

sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak.$(date +%F)
sudo tee /etc/nginx/conf.d/app.conf > /dev/null <<'EOF'
upstream app_upstream {
    server 127.0.0.1:3000;
    keepalive 32;
}
server {
    listen 80;
    server_name example.com;
    location / {
        proxy_pass http://app_upstream;
        proxy_http_version 1.1;
        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;
        proxy_connect_timeout 5s;
        proxy_send_timeout 30s;
        proxy_read_timeout 30s;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}
EOF
sudo nginx -t
sudo systemctl reload nginx

If you tell me your setup, I’ll tailor the exact Nginx config + the cloud steps

Reply with these details (short answers are fine):

  • OS on the instance (Ubuntu/CentOS/Rocky/Alma?)
  • Your goal: static site or reverse proxy (and app port)
  • Do you have a domain mapped to the instance public IP?
  • Have you opened security group ports 22/80/443 yet?
  • Any error message from browser or Nginx logs

Then I can provide a concrete server block, expected file paths for your distro, and a precise troubleshooting path if it doesn’t go live on the first attempt.

TelegramContact Us
CS ID
@cloudcup
Contact
TelegramSupport
CS ID
@yanhuacloud
Contact