How to Run HTTP and HTTPS Sites on One SNI Server With NGINX

Yes—you can host many HTTP and HTTPS websites on one NGINX server and one IP address. Create port-80 virtual hosts for each hostname, create matching TLS virtual hosts that listen on port 443, and give each TLS block a certificate covering its server_name. SNI puts the requested hostname in the TLS handshake so NGINX can select the right certificate and site. If every site must be secure, make each port-80 block return 301 https://$host$request_uri.

Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.

The configuration below uses two domains, but the same pattern scales to additional names. Replace the example hostnames, certificate paths, document roots, and upstream addresses with values from your deployment, then run nginx -t before reloading NGINX.

#	Preview	Product	Price
1		NGINX Cookbook: Advanced Recipes for High-Performance Load Balancing	$37.53	Buy on Amazon
2		NGINX Cookbook: Over 70 recipes for real-world configuration, deployment, and performance	$23.69	Buy on Amazon
3		NGINX Unit Cookbook: Recipes for Using a Versatile Open Source Server	$12.31	Buy on Amazon
4		NGINX HTTP Server: Harness the power of NGINX with a series of detailed tutorials and real-life...	$51.99	Buy on Amazon
5		NGINX Cookbook: Advanced Recipes for High-Performance Load Balancing	$26.99	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

How SNI lets several HTTPS sites share one IP

In a traditional HTTPS connection, the server needs to know which certificate to present during the TLS handshake. When several domains share one address, the client supplies the requested hostname through Server Name Indication (SNI), an extension defined by RFC 6066. NGINX reads that name early in the handshake and chooses the matching server block and certificate. After TLS is established, normal HTTP request processing uses the request line and, where applicable, the Host header to select the content configuration.

This is why one address can serve site-one.example and site-two.example without a separate IP for each. The client must support SNI, DNS for every name must resolve to the NGINX address, and each certificate must cover every name that clients use. A client that does not send SNI cannot identify the intended site at handshake time; it receives the certificate from the default TLS server instead.

#1 Best Overall

Sale

NGINX Cookbook: Advanced Recipes for High-Performance Load Balancing

$37.53

Buy on Amazon

Prerequisites to check before editing NGINX

• DNS: Create address records for every hostname and make sure they resolve to the server’s public address. Include both the bare name and www only if you intend to serve both.
• Reachable ports: Permit TCP 80 and TCP 443 through the host firewall, cloud security group, load balancer, and any upstream network device that sits in front of NGINX.
• NGINX SSL support: The build must include the HTTP SSL module. The TLS virtual hosts require listen 443 ssl, ssl_certificate, and ssl_certificate_key.
• Certificates: Obtain a certificate and private key for each hostname set, or choose a certificate that deliberately covers several names. The certificate’s names must match every value in the corresponding server_name directive.
• Content or an upstream: Decide whether NGINX will serve files directly from a root directory or proxy requests to an application server.
• Key protection: Restrict private-key permissions so that only the NGINX master process and the administrators who manage certificates can read them.

The paths in examples such as /etc/letsencrypt/live/site-one.example/fullchain.pem are illustrative. They are not proof that a particular certificate automation method or directory layout is present on your system.

Choose a server-block layout

There are two sound ways to express the HTTP/HTTPS relationship. Separate blocks make the redirect behavior obvious and let the HTTP and HTTPS sites evolve independently. A single block can listen on both ports when the same virtual host should handle both protocols; NGINX documents this as placing one listen directive without SSL and one with the ssl parameter in the same server.

Recommended configuration: redirect HTTP and serve two HTTPS sites

This pattern gives each hostname a clear port-80 redirect and a separate TLS block. It preserves the original host and URI: $host supplies the requested hostname and $request_uri includes the path and query string.

Rank #2

Sale

NGINX Cookbook: Over 70 recipes for real-world configuration, deployment, and performance

$23.69

Buy on Amazon

# HTTP to HTTPS redirect for site one
server {
    listen 80;
    server_name site-one.example www.site-one.example;
    return 301 https://$host$request_uri;
}

# HTTPS site one
server {
    listen 443 ssl;
    server_name site-one.example www.site-one.example;

    ssl_certificate     /etc/letsencrypt/live/site-one.example/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/site-one.example/privkey.pem;

    root /var/www/site-one;
    index index.html;
}

# HTTP to HTTPS redirect for site two
server {
    listen 80;
    server_name site-two.example www.site-two.example;
    return 301 https://$host$request_uri;
}

# HTTPS site two
server {
    listen 443 ssl;
    server_name site-two.example www.site-two.example;

    ssl_certificate     /etc/letsencrypt/live/site-two.example/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/site-two.example/privkey.pem;

    root /var/www/site-two;
    index index.html;
}

Place these blocks in the configuration location used by your NGINX installation, such as an included virtual-hosts file. Replace every example value before enabling it. The two port-443 blocks may share the same IP because SNI distinguishes their names during the handshake.

What each directive does

• listen 80; accepts cleartext HTTP on the conventional port.
• listen 443 ssl; accepts TLS connections and enables SSL handling for that listener.
• server_name lists the names that map to the block. If users can enter both the bare and www forms, list both and cover both in the certificate.
• ssl_certificate points to the certificate chain presented to clients.
• ssl_certificate_key points to the corresponding private key. The key must match the certificate.
• root selects the directory from which static files are resolved, and index identifies the default file.
• return 301 ends the port-80 request immediately with a permanent redirect instead of serving duplicate cleartext content.

Serving static files or proxying an application

The certificate and SNI portion is the same whether the HTTPS block serves files or forwards requests. For a static site, keep the root and index directives in the TLS block. For an application, replace or supplement them with a location that proxies to the appropriate upstream.

Static site per hostname

server {
    listen 443 ssl;
    server_name site-one.example www.site-one.example;

    ssl_certificate     /path/to/site-one/fullchain.pem;
    ssl_certificate_key /path/to/site-one/privkey.pem;

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

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

The try_files choice shown here returns a 404 when neither a file nor a directory exists. A single-page application may need a different fallback, while a conventional file tree may not need a custom location at all; choose behavior that matches the application rather than copying this line blindly.

Rank #3

Sale

NGINX Unit Cookbook: Recipes for Using a Versatile Open Source Server

$12.31

Buy on Amazon

Reverse proxy per hostname

server {
    listen 443 ssl;
    server_name site-two.example www.site-two.example;

    ssl_certificate     /path/to/site-two/fullchain.pem;
    ssl_certificate_key /path/to/site-two/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        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;
    }
}

Use a distinct upstream address or port for each application when they run on the same machine. The TLS certificate still belongs in the NGINX block; the application can remain HTTP on its loopback interface if that is the intended trust boundary.

One combined block for both protocols

If a hostname is deliberately available over both HTTP and HTTPS, NGINX can attach both listeners to one block:

server {
    listen 80;
    listen 443 ssl;
    server_name site-one.example www.site-one.example;

    ssl_certificate     /path/to/site-one/fullchain.pem;
    ssl_certificate_key /path/to/site-one/privkey.pem;

    root /var/www/site-one;
    index index.html;
}

This arrangement is not an HTTP-to-HTTPS redirect. Requests arriving on port 80 are handled by the same content configuration. Use the separate redirect-and-content pattern when cleartext must never return the site, when cookies or credentials require TLS, or when policy requires every URL to be canonicalized to HTTPS.

Rank #4

NGINX HTTP Server: Harness the power of NGINX with a series of detailed tutorials and real-life examples

$51.99

Buy on Amazon

Certificate choices for multiple names

SNI selects a server block, but the certificate presented by that block still has to cover the hostname. You can represent the names in several ways:

Do not infer coverage from a filename. Inspect the certificate’s names and ensure every value in server_name is covered. If the certificate and private key do not form a pair, NGINX will reject the configuration or the TLS handshake will fail.

Deployment procedure

1. Inventory names and destinations. Write down every public hostname, whether its HTTP form should redirect, its document root or upstream, and the certificate and key paths that will serve it.
2. Publish DNS. Point each name to the address that reaches this NGINX instance. Wait for the records to resolve from the networks your users will use before interpreting certificate or routing errors.
3. Create content or upstreams. Make /var/www/site-one and the other roots readable by the NGINX worker process, or start the applications that NGINX will proxy to. Verify each destination locally before adding TLS complexity.
4. Install certificate files securely. Put the full certificate chain and matching private key at the paths in the TLS blocks. Keep the private key readable only by the NGINX master process and authorized administrators.
5. Add one port-80 block per hostname set. Use the exact names that DNS and the certificate cover. Return a 301 redirect when the site is HTTPS-only.
6. Add one port-443 block per TLS selection. Set listen 443 ssl, the matching server_name, both certificate directives, and either static-file or proxying directives.
7. Define unmatched-host behavior. Decide which server should be the intentional default for port 80 and port 443. A default can return a controlled error or a neutral response instead of exposing the first site’s content.
8. Validate before applying. Run nginx -t. Fix every syntax error, missing file, permission error, duplicate conflict, or certificate/key mismatch it reports.
9. Reload gracefully. Use your operating system’s NGINX service reload mechanism after the test succeeds. A reload lets existing connections finish while workers adopt the new configuration; use the service manager command appropriate to your installation.
10. Test both protocols and every name. Request each HTTP hostname and confirm the Location header points to the same host over HTTPS. Then connect to each HTTPS hostname and verify the certificate name, response content, redirects, and application routing.

How NGINX chooses a block, in order

Port 80

NGINX first groups listeners by address and port, then compares the HTTP request’s host information with server_name. The matching port-80 block returns the redirect or serves cleartext content. If no name matches, the listener’s default server handles the request, which is why an explicit default is preferable to accidental first-file behavior.

Best Value

NGINX Cookbook: Advanced Recipes for High-Performance Load Balancing

$26.99

Buy on Amazon

Port 443

For TLS, the SNI name arrives during the handshake. NGINX uses it to choose the certificate and TLS server block before the encrypted HTTP request is available. Once the handshake succeeds, request processing can use the HTTP host value to select the appropriate configuration. A wrong certificate therefore points first to SNI, certificate coverage, or default-server selection—not to the document root.

Default servers and unmatched hostnames

Shared-IP hosting needs a deliberate response for names you did not configure. Without one, NGINX may answer with whichever server is the default for that address and port. That can expose the wrong site’s certificate or content and makes troubleshooting difficult.

# Intentional HTTP default
server {
    listen 80 default_server;
    server_name _;
    return 444;
}

# Intentional HTTPS default
server {
    listen 443 ssl default_server;
    server_name _;

    ssl_certificate     /path/to/default/fullchain.pem;
    ssl_certificate_key /path/to/default/privkey.pem;
    return 444;
}

The example uses a deliberately controlled response for unknown hosts. Select a response that fits your monitoring and security policy. A TLS default still needs a certificate because the handshake occurs before NGINX can return an HTTP response; non-SNI clients will see this default certificate.

Non-SNI clients and when one IP is not enough

Modern browsers generally send SNI, but an old client, embedded device, or specialized TLS library may not. A non-SNI client cannot tell NGINX which certificate it wants, so the default TLS block supplies the certificate. If that certificate does not contain the requested hostname, the client reports a name mismatch even though a matching server block exists.

There are two documented ways to accommodate such clients: assign separate IP addresses so the address itself selects the site, or use one multi-name certificate that covers the names those clients need. Separate addresses consume more network resources; a shared certificate couples the names operationally. Choose based on the clients you actually must support rather than disabling SNI-based separation.

Quick Recap

SaleBestseller No. 1

NGINX Cookbook: Advanced Recipes for High-Performance Load Balancing

$37.53

SaleBestseller No. 2

NGINX Cookbook: Over 70 recipes for real-world configuration, deployment, and performance

$23.69

SaleBestseller No. 3

NGINX Unit Cookbook: Recipes for Using a Versatile Open Source Server

$12.31

Bestseller No. 4

NGINX HTTP Server: Harness the power of NGINX with a series of detailed tutorials and real-life examples

$51.99

Bestseller No. 5

NGINX Cookbook: Advanced Recipes for High-Performance Load Balancing

$26.99

Validation and troubleshooting

Security and maintenance considerations

• Keep the redirect policy consistent. If a site is intended to be HTTPS-only, give every cleartext hostname a redirect block, including alternate names you publish.
• Renew before expiry. When a certificate is replaced, update the chain and key paths atomically where your deployment method permits, run nginx -t, and reload only after validation.
• Review protocol settings against your NGINX version. TLS protocol defaults and directive behavior can change; use the current NGINX SSL-module reference for version-specific settings instead of copying an old hardening snippet.
• Limit key exposure. Certificate chains are public, private keys are not. Keep backups protected and ensure logs, configuration archives, and deployment artifacts do not disclose keys.
• Separate names intentionally. Do not place unrelated domains in one server_name list merely to reduce file count. Group names only when they share certificate coverage, content, redirect policy, and lifecycle.
• Monitor each hostname. A shared listener can remain healthy while one certificate expires or one upstream stops responding. Check every public name, not just the server address.

Practical design checklist

• Every hostname resolves to the NGINX address.
• Every public name appears in exactly the intended port-80 and port-443 server_name lists.
• Every TLS block has listen 443 ssl, a certificate, and its matching private key.
• Certificate names cover both apex and www forms when both are published.
• Port 80 either redirects deliberately or serves content deliberately; it is not accidental.
• Static roots and upstream destinations are different for sites that must remain isolated.
• An explicit default server handles unknown and non-SNI traffic.
• Private keys are readable only by the NGINX master process and authorized operators.
• nginx -t succeeds before every reload.
• Tests cover redirects, certificate identity, content, error handling, and application paths for every hostname.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.