Azure Prepaid Account How to Install and Configure Nginx on Azure VM

Azure Account / 2026-05-16 22:43:29

Why Nginx on an Azure VM (and why it might love you back)

So you want to install and configure Nginx on an Azure Virtual Machine. Great choice. Nginx is fast, reliable, and the kind of software that won’t demand emotional support. Azure VMs, meanwhile, provide the flexibility to run almost anything, which is wonderful—right up until you discover you accidentally exposed port 22 to the whole internet. (Relax, we’ll include sensible safety steps.)

In this article, you’ll do the following:

  • Create and connect to an Azure VM
  • Install Nginx on a Linux VM
  • Open the right ports in Azure and in the OS firewall
  • Configure Nginx server blocks (virtual hosts)
  • Optionally set up HTTPS with Let’s Encrypt
  • Test, troubleshoot, and optimize your setup

We’ll keep the instructions clear and repeatable, so you can follow along without feeling like you need a PhD in cloud networking to serve a webpage.

Prerequisites: What you should have before you start

1) An Azure account and a VM

You’ll need an Azure subscription and permission to create a Virtual Machine. If you already have a VM, you can skip ahead to the installation steps.

For Nginx, a Linux VM is typical. Popular choices include Ubuntu Server and Debian. The commands in this guide are most aligned with Ubuntu/Debian-style systems. If your VM is based on a different distro (hello, CentOS/RHEL), you can still do it, but you’ll need to translate a few package manager names and service commands.

2) Basic access to the VM

You should be able to SSH into your VM. Azure provides SSH access via the portal and/or CLI, and your VM can be set up with an SSH key for secure login. If you’re still using password authentication and it’s your first time, consider switching to SSH keys. Attackers don’t typically show up holding flowers. They show up with scripts.

3) A domain name (optional, but recommended)

If you want HTTPS, you’ll need a domain (or at least a hostname that points to your VM). Let’s Encrypt generally needs the domain to resolve to your server. If you don’t have a domain, you can still run HTTP, test Nginx, and configure everything first—then add HTTPS later.

Step 1: Create an Azure VM (quick and sensible)

In the Azure portal, create a new Virtual Machine. Choose:

  • Region: Pick one close to your users (latency matters).
  • Image: Ubuntu Server (commonly easiest).
  • Authentication: SSH public key (best practice).
  • Inbound ports: If the portal offers it, you can choose HTTP (80) and HTTPS (443) later, but it’s often handy to select them during setup.

About inbound ports: you can open them now or later, but don’t leave the VM exposed randomly “because it works.” We’ll open only what you need.

After creation, get the VM’s public IP address from the portal. That IP is your first way to verify Nginx is alive.

Step 2: Connect to your VM over SSH

Azure Prepaid Account From your local machine, connect using SSH. A typical command looks like this:

ssh -i /path/to/your-key.pem azureuser@<public-ip>

Replace /path/to/your-key.pem and azureuser with your actual SSH key path and VM username.

If you’re unsure of the username, check Azure VM settings or the image defaults.

Step 3: Update the system packages

Before installing anything, update your package index. On Ubuntu/Debian:

sudo apt update
sudo apt upgrade -y

This reduces the chance you’ll hit “works on my machine” vibes later. Sometimes you’ll also need reboot changes, but usually package upgrades here are straightforward.

Step 4: Install Nginx

Install Nginx using apt:

sudo apt install -y nginx

Once installed, start the service and enable it at boot:

sudo systemctl start nginx
sudo systemctl enable nginx

Check status:

sudo systemctl status nginx --no-pager

Azure Prepaid Account If you see it running, congratulations: you’ve just successfully invited Nginx to your party.

Step 5: Allow web traffic in Azure (Network Security Group)

Here’s the twist: installing Nginx doesn’t automatically open firewall access at the Azure network level. You must allow inbound traffic to your VM.

In Azure, you typically use a Network Security Group (NSG) attached to the VM’s network interface or subnet. You must add inbound rules for:

  • HTTP (80/TCP)
  • HTTPS (443/TCP) if you plan to enable TLS
  • SSH (22/TCP) for your own access (optional but usual)

Make sure the rules are limited to the sources you need. If you can restrict SSH to your IP address, do it. You’ll sleep better.

Step 6: Allow web traffic in the OS firewall (UFW, if enabled)

Some Azure images may include UFW (Uncomplicated Firewall). You can check if it’s active:

sudo ufw status

If UFW is not active, you’re done on that front. If it is active, allow ports:

sudo ufw allow 'Nginx Full'

Or allow specifically:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Then reload if necessary (UFW usually applies changes immediately):

sudo ufw reload

Again: don’t panic. Just make sure both Azure and the VM OS allow inbound traffic.

Step 7: Verify Nginx is serving content

Nginx on Ubuntu generally serves its default page from a directory like:

  • /var/www/html (common default)
  • and configuration in /etc/nginx/sites-available and /etc/nginx/sites-enabled

To test locally on the VM:

curl -I http://localhost

You should see a response header with status code 200 or 302.

To test externally: open a browser on your local machine and visit:

http://<public-ip>

If you see the default Nginx welcome page, that’s proof your installation, Azure rules, and OS firewall are all cooperating like polite grown-ups.

If not, don’t worry. We’ll cover troubleshooting later in a dedicated section.

Step 8: Understand Nginx configuration basics (without the pain)

Nginx configuration can feel like a maze if you treat it like a novel. But it’s mostly simple if you focus on the main pieces:

  • Main config: /etc/nginx/nginx.conf
  • Server blocks (virtual hosts): /etc/nginx/sites-available and /etc/nginx/sites-enabled
  • Enabled config links: The sites-enabled directory typically has symlinks to sites-available configurations
  • Logs: /var/log/nginx/access.log and /var/log/nginx/error.log

Think of server blocks as “rules for handling requests for specific hostnames and paths.” If you set one up for your domain, Nginx will route requests correctly.

Step 9: Configure your site using a server block

Let’s move from “default welcome page” to “your own site.” We’ll create a new server block.

Choose your document root

For example, you might use:

/var/www/myapp

Create it and place a test file inside:

sudo mkdir -p /var/www/myapp
echo '<!doctype html> <html> <body> <h1>Nginx is working on Azure VM!</h1> <p>If you can read this, you did the thing.</p> </body> </html>' | sudo tee /var/www/myapp/index.html

Now we’ll create a server block for this site.

Create a new site config file

On Ubuntu, a common approach is to create a file in /etc/nginx/sites-available and enable it via symlink into sites-enabled.

Azure Prepaid Account Create a config like:

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

Paste the following. Replace server_name with your domain if you have one. If not, you can temporarily use the IP or a placeholder like localhost.

server {
    listen 80;
    listen [::]:80;

    server_name _;

    root /var/www/myapp;
    index index.html index.htm;

    location / {
        try_files $uri $uri/ =404;
    }
}

A quick note about server_name _;: it’s a catch-all. If you later configure domain-based routing, you’ll set server_name yourdomain.com;. For now, this keeps things simple and ensures the server block responds.

Save and exit.

Enable the site

sudo ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/

Now disable the default site if you don’t want it to interfere:

sudo unlink /etc/nginx/sites-enabled/default

If your distribution uses different paths, double-check by listing sites-enabled:

ls -l /etc/nginx/sites-enabled

Test Nginx configuration and reload

Always validate your Nginx config before reloading. This prevents silly mistakes from taking your server down.

sudo nginx -t

If it says the configuration is successful, reload Nginx:

sudo systemctl reload nginx

Now visit your VM IP again:

http://<public-ip>

You should see your custom message.

Step 10: Make Nginx behave nicely (basic best practices)

By now, Nginx is serving content. That’s the core job. But you can improve usability and resilience.

Enable sensible error pages

Nginx can serve default error pages automatically, but you can also create custom ones later. For now, ensure your error logs are monitored so you’re not flying blind.

Use correct permissions and ownership

If your deployment process writes to /var/www/myapp, ensure the permissions align with your deployment user. Avoid giving overly broad permissions just because it “works.” Overly broad permissions are how servers become storytellers of regret.

Azure Prepaid Account Consider adding gzip (optional)

Gzip can improve performance by compressing responses. You can enable it in a relevant config file or in /etc/nginx/nginx.conf. Many default configs already include it.

If your config doesn’t have it, you can add something like this to an appropriate server block:

 gzip on;
 gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

Test and reload after changes.

Step 11: Add HTTPS using Let’s Encrypt (the “please, I like secure” step)

HTTP is fine for testing, but HTTPS is what you want for real-world use. Let’s Encrypt via Certbot is the most common approach.

Important: Certbot needs to reach your VM from the internet to validate domain ownership. So you’ll need a domain pointed to your VM’s public IP.

Install Certbot

On Ubuntu/Debian:

sudo apt install -y certbot python3-certbot-nginx

Update your server block to use your domain

Replace server_name _; with your domain, for example:

server_name yourdomain.com www.yourdomain.com;

Make sure your Nginx config is valid after modifications, then reload.

Azure Prepaid Account Obtain and install the certificate

Run Certbot:

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

Follow prompts. Certbot usually configures the HTTPS server block automatically and can optionally redirect HTTP to HTTPS.

If Certbot asks how to handle redirects, choose the option that redirects HTTP to HTTPS unless you have a reason not to.

Test renewal

Azure Prepaid Account Let’s Encrypt certs are typically valid for about 90 days. Certbot should install a systemd timer for automatic renewal.

Check renewal:

sudo certbot renew --dry-run

If the dry run succeeds, you’re in good shape.

Step 12: Test everything like you mean it

Here are practical tests to confirm your setup is correct.

Check Nginx configuration

sudo nginx -t

Check listening ports

sudo ss -tulpn | grep nginx

You should see port 80 and possibly 443.

Check responses locally

HTTP:

curl -I http://localhost

HTTPS (replace with your domain):

curl -I https://yourdomain.com

You should see a secure response and likely a 200 OK (or 301/302 if redirecting).

Check logs when something feels off

Watch error logs in real time while you test:

tail -f /var/log/nginx/error.log

And for request-level debugging:

tail -f /var/log/nginx/access.log

If you see 404 errors, it’s usually document root or server block issues. If you see 502/504 errors, it could be upstream or proxy misconfiguration (not typical for a static site).

Common troubleshooting (a.k.a. “Why is my website doing interpretive dance?”)

1) “I installed Nginx, but the page doesn’t load”

Most common causes:

  • Azure NSG rule not allowing inbound traffic to port 80/443
  • OS firewall (UFW) blocking inbound traffic
  • Nginx not running
  • Default site disabled but your new site is not enabled or contains errors

Fix path:

  • Run: sudo systemctl status nginx --no-pager
  • Run: sudo nginx -t
  • Verify you can curl locally: curl -I http://localhost

If local curl works but external doesn’t, it’s almost always network rules.

2) “502 Bad Gateway”

This usually happens when Nginx is proxying to an upstream service (like an app server) and the upstream is down or misconfigured. For a static site, you shouldn’t see 502.

If you’ve added proxy settings (not covered deeply in this article), check your upstream host/port and ensure the backend service is running and reachable from the VM.

3) “404 Not Found”

Common reasons:

  • You set the wrong document root
  • The server block isn’t being used for your request (server_name mismatch)
  • The file doesn’t exist where Nginx expects it

Check:

  • Document root directory exists and contains index.html
  • Server block has correct server_name (especially after adding HTTPS)

4) “Certbot fails”

Typical causes:

  • Domain DNS doesn’t point to your VM’s public IP
  • Port 80 isn’t reachable for HTTP-01 validation
  • Firewall rules block inbound traffic

Quick checks:

  • Ensure NSG allows inbound 80 during validation
  • Ensure UFW allows 80
  • Verify domain resolves to the VM public IP

Azure Prepaid Account Performance and security tips (the “don’t let your VM become a hobby” list)

Keep Nginx updated

Security patches matter. Regularly update your system packages:

sudo apt update
sudo apt upgrade -y

Restrict SSH exposure

Try to restrict port 22 inbound access to your IP address in Azure NSG. This is one of the simplest risk-reduction steps you can take.

Use least privilege for deployment

If your app is deployed via CI/CD, use an appropriate user and permissions. Avoid logging in as root for everything unless you truly enjoy living dangerously.

Enable automatic security headers (optional)

You can add headers like:

  • Strict-Transport-Security (when using HTTPS)
  • X-Content-Type-Options
  • X-Frame-Options
  • Content-Security-Policy (best if you know your app)

Not required for basic operation, but helpful for hardening. Use with caution so you don’t break your site unexpectedly.

Consider rate limiting (optional)

If you’re exposing a public endpoint, you may want to limit repeated requests, especially for login routes. Nginx can do rate limiting, but this guide stays focused on installation and basic configuration.

A simple deployment workflow (so future-you doesn’t cry)

Once you have Nginx serving static content, deployment is easy. A typical workflow:

  1. Update your website files in /var/www/myapp (or a staging directory)
  2. Ensure correct permissions
  3. Test Nginx configuration if you changed it: sudo nginx -t
  4. Reload Nginx only when needed: sudo systemctl reload nginx
  5. Azure Prepaid Account Verify site from an external browser

If you later deploy a dynamic app (Node, Python, PHP), you’ll likely add proxying and upstream configs. But the installation and base structure remain the same.

Wrap-up: You now have Nginx on Azure doing its job

You installed Nginx, configured server blocks, opened the right ports, and tested your setup. If you added HTTPS, you also wrangled certificates like a seasoned wizard (or at least like a determined intern with a good checklist).

To recap the most important steps:

  • Install Nginx and ensure the service is running
  • Open inbound ports in Azure NSG (80 and 443 as needed)
  • Allow ports in the VM firewall if UFW is enabled
  • Create a site configuration in /etc/nginx/sites-available and enable it
  • Validate config with nginx -t and reload with systemctl reload nginx
  • Optionally set up HTTPS with Let’s Encrypt via Certbot

If something didn’t work, you now also know where to look: Nginx status, configuration test, local curl, Azure NSG rules, OS firewall, and logs.

Next step suggestion: decide how you want to deploy your content or application, then refine Nginx settings for that specific use case. Nginx can be minimal or magnificent—the choice is yours.

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