What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Yes—you can host several domains on one NGINX server and one IP address. Create a port-80 virtual host for each domain, create a matching TLS virtual host on port 443, and give each HTTPS block a certificate whose names cover its server_name values. Server Name Indication (SNI) lets the browser send the requested hostname during the TLS handshake, so NGINX can select the correct certificate and server block. If every site should use HTTPS, make each port-80 block return a permanent redirect to its HTTPS URL.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
How one IP can serve many HTTP and HTTPS domains
NGINX distinguishes sites by the hostname supplied by the client. Cleartext HTTP includes the hostname in the request, while HTTPS needs the hostname early enough to choose a certificate. SNI solves that TLS problem: the browser sends the requested server name during the handshake, and NGINX uses it to select the matching TLS virtual server on the shared address.
As an Amazon Associate I earn from qualifying purchases.
The usual layout is therefore two listeners for every site:
- Port 80: an HTTP virtual host that either serves content or, more commonly, redirects to HTTPS.
- Port 443: an HTTPS virtual host with
listen 443 ssl, the matchingserver_name, a certificate, a private key, and the site’s content or proxy settings.
NGINX documentation describes SNI as the generic way to run several HTTPS servers on one IP address. It also permits a single server block to contain one listen directive without ssl and another with ssl, so HTTP and HTTPS can be handled together when that behavior is wanted.
#1 Best Overall
Choose a virtual-host design
Separate redirect and HTTPS blocks
Use separate blocks when HTTP must always redirect and HTTPS must serve a site. This is the clearest arrangement: port 80 has no certificate settings and performs only the redirect, while port 443 owns TLS and the application or files.
| Design | HTTP behavior | HTTPS behavior | Best fit |
|---|---|---|---|
| Separate blocks | Dedicated port-80 block, commonly return 301 https://$host$request_uri; |
Dedicated port-443 TLS block with certificate, key and content/proxy settings | Sites that enforce HTTPS and need easy-to-audit configuration |
| One combined block | Same server block listens on 80; it can serve HTTP content | The same block also listens on 443 with ssl |
Deployments intentionally supporting both protocols without a redirect |
A combined block is valid, but it does not automatically redirect HTTP. If cleartext requests must be upgraded, separate port-80 redirect blocks avoid conditional logic and make the policy explicit.
One certificate per hostname, SAN, or wildcard
Each TLS block must present a certificate valid for the hostname the visitor requested. You can use an individual certificate for each site, a Subject Alternative Name (SAN) certificate containing several names, or a wildcard certificate where its scope covers the hostnames. The certificate choice changes certificate management, not the SNI mechanism.
| Certificate approach | What must match | Operational consideration |
|---|---|---|
| Per-hostname certificate | Every name in the block’s server_name must be included in that certificate |
Separate renewal and file paths for each site |
| SAN certificate | All listed DNS names must appear as certificate identities | One certificate can cover several names, but renewals affect all covered sites |
| Wildcard certificate | The wildcard pattern must cover each requested subdomain; the apex domain requires its own name unless also included | Fewer certificate files, with careful control of the shared private key |
Do not assume that a certificate for example.test also covers www.example.test; verify every name used in server_name.
Prerequisites before editing NGINX
- Point DNS for every hostname to the NGINX server’s address. Include both the apex and
wwwnames if both will be accepted. - Ensure the NGINX build includes the SSL module. The NGINX SSL module supplies the certificate, key and TLS directives used by the HTTPS blocks.
- Obtain certificates and private keys whose names cover the configured hostnames. The paths in the example below are illustrative, not evidence of a tested deployment.
- Make sure only the NGINX master process, or the minimum required service account, can read private-key files.
- Decide what should happen to an unknown hostname. An intentional default server gives deterministic behavior instead of exposing whichever site happens to be loaded first.
- Confirm that firewalls, cloud security groups and any upstream load balancer allow TCP ports 80 and 443.
Build the configuration
Port-80 redirects and port-443 site blocks
The following template defines two independent sites. Replace the example names, certificate paths and document roots with values from your deployment.
Rank #2
# 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;
}Each server_name list is repeated on the HTTP and HTTPS sides so the same hostnames map to the same site. The redirect preserves the incoming host and path: $host supplies the selected hostname and $request_uri retains the path and query string. A 301 is permanent, so test carefully before deploying it broadly; browsers and intermediaries may cache the result.
Recommended Free Tools
Serving an application instead of static files
Replace the root and index directives with the appropriate reverse-proxy settings when a site runs behind an upstream application. Keep the TLS and server_name portions unchanged. The important separation is that SNI selects the correct HTTPS block first; that block can then serve files or pass the request to its own upstream.
A combined HTTP/HTTPS block
NGINX also supports a single block with both listeners:
server {
listen 80;
listen 443 ssl;
server_name site-one.example www.site-one.example;
ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
root /var/www/site-one;
index index.html;
}This pattern handles both protocols in one virtual server, as documented by NGINX. It serves HTTP unless additional logic changes that behavior. Choose it only when allowing cleartext traffic is intentional; use separate blocks when the requirement is an unconditional redirect.
How NGINX selects the right site
During the TLS handshake
When a browser connects to port 443, it sends the hostname in the SNI extension. NGINX uses that name to select the TLS server and present its certificate. This selection occurs before the encrypted HTTP request is available, which is why certificate names and TLS server_name values must be aligned.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchAfter encryption is established
Once the handshake completes, NGINX processes the HTTP request. Server-name selection can then use the request line or the HTTP Host header as applicable. A mismatch can send a request to a different block even when the certificate appeared correct, so keep names consistent across DNS, certificates, port-80 blocks and port-443 blocks.
What happens without SNI
Older or unusual clients that do not send SNI cannot tell NGINX which certificate they need during the handshake. They may receive the certificate from the default server for that address, producing a certificate warning or the wrong site. Separate IP addresses remain an option for non-SNI compatibility; a certificate containing multiple names is another documented alternative, although it does not make an SNI-less client communicate a preferred hostname.
Install, validate and activate the sites
- Create content or upstream definitions. Make
/var/www/site-oneand/var/www/site-two, or prepare the proxy destinations used by each application. - Obtain certificates. Confirm that every name in each
server_nameis covered. Record the full-chain and private-key paths and protect the key files. - Add the server blocks. Place the port-80 redirect and port-443 TLS block for each domain in the configuration location used by your NGINX installation.
- Check for conflicts. Search the active configuration for duplicate
server_namevalues on the same address and port, unintendeddefault_serverdeclarations, and certificate paths that do not exist. - Validate syntax and references. Run
nginx -t. Do not reload a configuration that fails this check; correct the reported file, line or permission problem first. - Reload NGINX. Use the service manager or control method appropriate to your installation so the master process adopts the validated configuration without an unnecessary stop.
- Test every hostname. Request each domain over HTTP and HTTPS, including both apex and
wwwnames if configured. Confirm that HTTP returns the intended 301 and that HTTPS presents the expected certificate and site content.
The documentation-backed template establishes the directives and selection behavior; it is not a test report for your particular filesystem, certificate authority, DNS zone or NGINX version.
Verification checklist
- DNS: Every hostname resolves to the address where this NGINX instance listens.
- Port mapping: TCP 80 reaches the HTTP listener and TCP 443 reaches the TLS listener.
- Name coverage: The certificate identity list includes every value in the corresponding
server_name. - Chain delivery: Use the full-chain file where clients require intermediate certificates, not only the leaf certificate.
- Private-key access: NGINX can read the key at startup or reload, while unrelated users cannot.
- Redirect target: The 301 points to the same hostname and requested URI over HTTPS.
- Content isolation: Each HTTPS block has the intended document root or upstream and does not inherit a neighboring site’s settings.
- Default behavior: Requests for unrecognized names go to an intentional default server or are rejected according to your policy.
Common failures and fixes
The browser shows the certificate for another site
Check whether the client sent SNI, whether the requested name exactly matches a TLS server_name, and whether that block is loaded on the address and port being tested. If the client is non-SNI, use a separate IP for compatibility or accept that it will receive the default certificate.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →HTTPS returns the wrong content
Inspect duplicate names and the order or default status of competing port-443 blocks. Confirm that the request’s hostname appears in the intended block and that its root or proxy target is not inherited from another configuration file.
HTTP does not redirect
Verify that the request reaches port 80, that the hostname is listed in the matching port-80 block, and that no earlier default server handles it. A combined block deliberately serves both protocols unless you add redirect behavior, so replace it with a dedicated redirect block when HTTPS enforcement is required.
nginx -t reports a certificate or key error
Check the spelling and permissions of ssl_certificate and ssl_certificate_key paths, ensure the files exist, and verify that the key corresponds to the certificate. Correct access for the NGINX master process before attempting another reload.
Only some names work
Compare DNS records, certificate identities and both sides of the virtual-host pair. A name omitted from DNS will not reach the server; a name omitted from the certificate will fail TLS validation; a name omitted from server_name may fall into the default block.
Free tools Windows power users keep installed
One-click scans. No signup required.
Changes appear ignored
Run nginx -t against the configuration actually used by the running service, then reload that service. Also check whether a load balancer or another NGINX instance terminates TLS before this server; SNI must be handled at the TLS termination point.
Operational choices and trade-offs
Shared IP with SNI versus separate IP addresses
SNI allows many modern HTTPS sites to share one IP, conserving addresses and keeping per-site configuration in NGINX. Separate addresses can improve compatibility with clients that do not send SNI and can simplify strict isolation, but they require additional address allocation and DNS management.
Individual certificates versus a shared certificate
Per-site certificates limit the impact of a renewal or key-management problem to one hostname and make ownership boundaries clear. SAN or wildcard certificates reduce the number of certificate files, but a single private-key compromise or renewal failure can affect several names. Choose according to your administration and isolation requirements.
Static files versus reverse proxies
Static sites need only the document root and index settings shown in the template. Applications add upstream health, timeout, header and deployment concerns, but the SNI and virtual-host selection process remains the same: NGINX chooses the TLS block by hostname, then that block handles files or proxying.
Version and policy notes
Directive defaults and supported TLS settings can vary with the NGINX version and build. Consult the current NGINX directive reference for version-specific protocol and SSL options rather than copying old defaults. Keep certificate renewal procedures synchronized with the paths in each TLS block, and re-run nginx -t before every reload that changes certificates or server names.
The essential rule is simple: publish DNS for each name, map each name to an HTTP block and a matching HTTPS block, provide a certificate that covers the name, and let SNI select the correct TLS configuration on the shared address.
Quick Recap
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.
