The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
The most practical arrangement is client HTTPS on Nginx port 443 → private HTTP Varnish listener (such as 127.0.0.1:6081) → origin Nginx or application on port 8080. Nginx owns the certificate and TLS policy, while Varnish applies cache rules. Keep the listeners separate, pass the original host and scheme, and verify each layer before putting traffic through it.
Use a deliberate request path
Varnish and Nginx should not bind to the same address and port. In the common Nginx-fronted design, Nginx is the only public TLS listener. It redirects plain HTTP, accepts HTTPS, and proxies the request to Varnish over a loopback or otherwise protected address. Varnish evaluates VCL and forwards misses to an origin listener that is no longer exposed on the public port.
| Layer | Example address | Responsibility | Internet exposure |
|---|---|---|---|
| Client edge | Nginx 443/tcp | Certificate, TLS protocols, HTTP-to-HTTPS redirect, request headers | Public |
| HTTP cache | Varnish 127.0.0.1:6081 | VCL, cache lookup, cache pass and hit decisions | Private |
| Origin proxy/application | Nginx or application 127.0.0.1:8080 | Dynamic application responses and static origin content | Private |
Port 6081 is Varnish’s conservative default in many installations. Port 80 is also valid when Varnish itself is the front proxy, but it is not needed for the Nginx-fronted pattern. The important rule is that every process has a distinct listener and that only the intended edge listener is reachable from the network.
Decide where HTTPS terminates
Nginx terminates client TLS (the usual choice)
Nginx loads the certificate and private key, negotiates TLS, and sends ordinary HTTP to a private Varnish listener. This keeps certificate renewal and edge TLS settings in one familiar reverse proxy. It is generally the simplest operational layout when Nginx already handles redirects, virtual hosts, or other edge headers.
#1 Best Overall
Varnish terminates client TLS
Varnish can listen on both HTTP and HTTPS when started with HTTPS listener options such as -a :80,http and -a :443,https. Its TLS setup uses a startup configuration that loads and commits certificates. Choose this only when Varnish is intentionally the edge proxy and your team is prepared to manage its certificate-loading workflow.
Encrypt the Varnish-to-origin hop
Varnish can connect to an HTTPS backend instead of an HTTP origin. Define the backend on port 443 and set .ssl = 1. This protects traffic between Varnish and the origin, which can matter when they are on different hosts or networks. It adds certificate and trust considerations to the backend connection, so do not enable it merely because the public endpoint uses HTTPS.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →| Design | Certificate location | Internal transport | Use when |
|---|---|---|---|
| Nginx TLS edge | Nginx | HTTP to private Varnish | You want a straightforward, Nginx-centered HTTPS deployment |
| Varnish TLS edge | Varnish | HTTP or HTTPS to the origin | Varnish is deliberately the public front proxy |
| Nginx edge plus encrypted backend | Nginx and, as needed, the backend connection | HTTPS from Varnish to origin | The internal network is not trusted or the origin requires encryption |
HTTP/2 or HTTP/3 requirements, certificate automation, observability, and operational ownership should be decided at the edge-terminator layer. Do not put both Nginx and Varnish on the same public TLS port while deciding.
Prepare the server and install Varnish
Check the prerequisites
- A Debian or Ubuntu server with administrative access.
- Nginx serving the site or acting as the origin proxy.
- A domain whose DNS points to the server, if you are obtaining a publicly trusted certificate.
- A certificate and private key readable by Nginx, with permissions that do not expose the key to unrelated users.
- An application decision about which responses are safe to cache.
Back up the Nginx virtual-host files and the Varnish service configuration before changing listeners. Record the current ports with ss -ltnp; this prevents an apparently correct configuration from failing because another process already owns the chosen port.
Install from the Varnish repository
Use the Varnish repository appropriate for your Debian or Ubuntu release, then install the package with your distribution’s package manager. A typical package installation is:
sudo apt update
sudo apt install varnishRepository package names and supported releases change, so follow the current repository instructions for your operating-system version rather than copying a repository line intended for a different release. After installation, inspect the unit that systemd is actually using:
Recommended Free Tools
systemctl cat varnish
systemctl status varnish --no-pagerThe packaged unit is commonly located at /lib/systemd/system/varnish.service. Distribution updates can replace that file, so a systemd drop-in is preferable for local changes. If you edit the unit directly, run systemctl daemon-reload before restarting the service.
Move the origin listener away from the public port
Varnish needs a backend port to contact. If Nginx currently serves the origin on port 80, move that origin listener to 8080 (or another unused, private port) before making Varnish depend on it.
Review every Nginx listen directive
Search the enabled server blocks and identify the origin listener:
grep -R "listen" /etc/nginx/sites-enabled /etc/nginx/conf.d 2>/dev/nullChange the intended origin server’s listen 80; directives to listen 8080;. A recursive replacement can be useful on a simple, known configuration, but review the result manually: a blind replacement may alter an HTTP redirect server, a default site, an IPv6 listener, or a deliberately separate virtual host.
If Nginx is both the public edge and the origin proxy, keep two logically separate server blocks. The public block listens on 443 and proxies to Varnish. The origin block listens only on 8080 and serves the application or static files. Bind the origin to 127.0.0.1:8080 when no other host needs to reach it; otherwise restrict access with the host firewall.
Check the syntax before proceeding:
sudo nginx -tDo not reload Nginx until the test reports successful syntax and configuration validation.
Choose and configure the Varnish listener
For an Nginx-fronted layout, bind Varnish to a loopback address such as 127.0.0.1:6081. This prevents clients from bypassing Nginx and reaching the cache directly. If Varnish and Nginx are on separate machines, use a private interface address and firewall the port so only the Nginx host can connect.
Change the systemd start command carefully
Inspect the existing ExecStart line and change only the listener and cache settings you intend to change. Keep the distribution’s user, management interface, VCL path, and other hardening options unless you have a reason to alter them. The listener portion should represent your selected address, for example 127.0.0.1:6081, rather than a public wildcard address.
Free tools Windows power users keep installed
One-click scans. No signup required.
After a unit-file edit:
sudo systemctl daemon-reload
sudo systemctl restart varnish
sudo systemctl status varnish --no-pagerA restart compiles the configured VCL and applies the runtime listener. If it fails, read the service log before changing more files:
journalctl -u varnish -n 100 --no-pagerSet the VCL backend
The file /etc/varnish/default.vcl defines where Varnish sends a miss or pass request. The standard starting point uses VCL 4.1 and an origin on loopback port 8080:
vcl 4.1;
backend default {
.host = "127.0.0.1";
.port = "8080";
}The host and port must exactly match the Nginx or application listener. If the origin uses another address, edit both values. A DNS name in VCL is resolved when the VCL is compiled; reload or restart the VCL after changing that DNS record so Varnish does not continue using the previously resolved address.
Start with generated behavior
Begin with the generated VCL and add policy only when you understand the response. Varnish’s default behavior is designed around an origin backend and standard HTTP cache semantics. A custom rule that removes cookies or ignores authorization can expose one user’s response to another user, so every override needs an application owner and a test case.
Define what must bypass cache
- Authenticated or personalized pages.
- Checkout, cart, account, and other user-specific workflows.
- Administrative interfaces and preview URLs.
- Requests with authorization credentials unless the application explicitly provides a shared response.
- State-changing methods such as POST, PUT, PATCH, and DELETE, unless a narrowly defined workflow requires a different policy.
- Responses that send private or no-cache directives.
Preserve the Host header, cookies, authorization information, and cache-control semantics unless the application has explicitly approved a transformation. A cache hit is useful only when the returned representation is correct for the requesting user and current application state.
Plan invalidation before enabling broad caching
Decide how content changes become visible: short object lifetimes, explicit purge or ban operations, versioned asset URLs, or a combination. The right policy depends on the application. Do not promise that every successful response will be cached, and do not treat an increasing hit count as proof that personalized content is safe to share.
Configure Nginx for HTTPS and Varnish
The public Nginx configuration needs one HTTP redirect server and one TLS server. Adapt the domain names and certificate paths to your deployment:
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name example.com www.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
location / {
proxy_pass http://127.0.0.1:6081;
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 https;
}
}Understand each important directive
listen 443 ssl;makes this server block the HTTPS listener. The certificate and private-key directives identify the files Nginx presents to clients.ssl_protocols TLSv1.2 TLSv1.3;limits negotiation to the protocols shown in the configuration. Review your operating system and OpenSSL support before tightening or expanding this list.proxy_pass http://127.0.0.1:6081;sends the decrypted request to Varnish over the private hop.proxy_set_header Host $host;preserves the requested hostname for virtual hosting, URL generation, and cache-key correctness.proxy_set_header X-Real-IP $remote_addr;passes the client address to the next layer.proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;maintains the proxy chain instead of replacing it.proxy_set_header X-Forwarded-Proto https;tells the application that the original client connection was HTTPS, preventing incorrect HTTP links or redirect loops.
The certificate paths in the example are a common convention, not a requirement for a particular certificate authority. Ensure the Nginx worker can read the key and that renewal tooling reloads Nginx after a successful renewal.
Apply changes in a safe order
- Confirm the origin server responds on its new private port, for example with
curl -I http://127.0.0.1:8080/. - Validate the VCL and restart Varnish. Check
systemctl status varnishand its journal for compilation or bind errors. - Run
sudo nginx -t. Fix every error before reloading. - Reload Nginx with
sudo systemctl reload nginxso existing connections are handled gracefully. - Confirm the expected listeners with
ss -ltnp. You should see Nginx on the public HTTP/HTTPS ports, Varnish on its selected private port, and the origin on 8080 or your chosen alternative. - Request the public HTTPS endpoint and inspect the response before changing cache rules.
Verify the complete path
Check the certificate and redirect
curl -I http://example.com/
curl -I https://example.com/The HTTP request should receive the configured redirect. The HTTPS request should complete a certificate handshake and return the response from the Nginx-to-Varnish-to-origin chain. A redirect loop usually means the application is unaware of X-Forwarded-Proto: https or another proxy layer is rewriting the scheme.
Check Varnish behavior with two requests
curl -I https://example.com/cacheable-path
curl -I https://example.com/cacheable-pathCompare the headers and timing, but do not assume that every second request must be a hit. Look for the cache indicators your deployment exposes, such as Via, Age, or application-specific cache headers. Cookies, authorization, cache-control directives, an uncacheable method, or a VCL pass rule may correctly prevent storage.
Best Value
Test private and state-changing paths
- Log in as one test user, request a personalized page, and confirm that another test user cannot receive the first user’s representation.
- Exercise cart, checkout, account, and administrative URLs and verify they bypass or invalidate cache as designed.
- Submit a state-changing request and confirm that subsequent reads reflect the change.
- Inspect Varnish statistics and logs together with Nginx error logs after each topology change.
These checks validate routing and policy; they are not a performance benchmark. Cache-hit rates and response-time improvements depend on the application, traffic mix, object lifetimes, and invalidation design.
Troubleshoot by symptom
Nginx fails to reload with an address-in-use error
Another process is listening on the port named in the error, or both an old and new server block claim it. Run ss -ltnp, remove the duplicate listener, and test again with nginx -t. Do not solve the problem by moving both services to a random public port; assign one deliberate edge listener and one private cache listener.
Outdated 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 matchPC 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 & 11Varnish cannot start
Check the journal for a VCL compilation error, an invalid listener address, or a port already in use. Confirm that the backend declaration is valid VCL 4.1, that the origin port is reachable locally, and that the systemd unit points to the file you edited. If you changed the unit, ensure systemctl daemon-reload ran before the restart.
The site returns 503 from Varnish
A 503 commonly means Varnish cannot reach its backend or the backend is unhealthy. Test the origin directly on 8080, verify the backend host and port in /etc/varnish/default.vcl, and inspect both service logs. If the origin is bound only to an address different from the VCL host, make the two definitions match or bind the origin to the intended loopback address.
The application redirects HTTPS requests back to HTTP
Ensure Nginx sets X-Forwarded-Proto https and that the application trusts that proxy header. Also check that an intermediate proxy is not overwriting it. The cache layer should not be used to conceal an incorrect scheme signal.
Clients can bypass the cache
If Varnish is reachable on a public address or port, clients can avoid Nginx’s TLS and header policy. Bind Varnish to loopback or a private interface and enforce the restriction with the host firewall. Keep the origin listener private as well; otherwise users can bypass both TLS edge policy and cache policy.
Cached content appears stale or belongs to the wrong user
First identify whether the response is personalized, cookie-dependent, authorization-dependent, or governed by a no-cache directive. Restore the default behavior for that path, remove any rule that strips relevant cookies or headers, and purge objects that were cached under the unsafe policy. Then retest with separate authenticated and anonymous clients.
Operational safeguards after launch
- Keep certificate files and private keys protected, and verify renewal reloads the Nginx configuration.
- Document the public and private ports, the VCL path, the systemd override, and the owner of cache invalidation rules.
- Monitor Nginx errors, Varnish logs, backend health, and listener availability rather than relying on a single cache header.
- Reload VCL deliberately after DNS changes because VCL hostnames are resolved when the VCL is compiled.
- Use a maintenance procedure that can temporarily route around Varnish if a policy change causes incorrect content.
- Review cache rules whenever the application adds authentication, personalization, checkout, preview, or API endpoints.
The durable pattern is simple: terminate client TLS in one intentional place, give Nginx and Varnish separate listeners, connect Varnish to a clearly defined origin backend, preserve identity and scheme headers, and prove each hop with direct and public requests before enabling wider caching.
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.
