Installing a valid TLS certificate on your server solves only half of the encryption problem. You bind the certificate, verify the handshake over port 443, open a fresh browser session, and watch port 80 stubbornly serve unencrypted plaintext. The padlock stays missing because SSL termination and HTTP redirection are entirely decoupled operations. Nginx accepts connections on whatever port you define, but it will never upgrade transport security automatically unless you explicitly instruct it to issue a redirect.

On an Apache deployment, engineers habitually drop rewrite rules into a .htaccess file and move on. Under Nginx on a managed control panel like Webuzo, that approach fails completely. Nginx does not parse runtime directory overrides, and hardcoding directives straight into the core server blocks will backfire the moment the panel rebuilds its configuration templates.

To force transport encryption reliably without your changes getting wiped, you need to leverage the panel's native injection hook.

---

Architectural Context: The Webuzo Nginx Pipeline

Webuzo orchestrates virtual hosts dynamically. When you apply domain updates, renewals, or stack adjustments, Webuzo regenerates the master nginx.conf file from underlying templates. Manually editing configuration files via SSH creates brittle infrastructure because your custom rules get overwritten during the next provisioning cycle.

Instead, Webuzo exposes an Extra Configuration interface. Snippets injected through this mechanism persist across template rebuilds and load directly into the active server context.

The Redirect Mechanism

To bounce unencrypted requests to the secure endpoint, we evaluate the connection scheme before execution hits application logic:

nginx
if ($scheme = http) {
     return 301 https://www.$server_name$request_uri;
}

While using if directives inside Nginx location blocks is notoriously risky, using if at the server level paired immediately with a clean return 301 is standard practice for scheme-level enforcement. It short-circuits the pipeline instantly, returning a permanent redirect response with low resource overhead.

---

Configuration Blueprints: Standard vs. WordPress

Create a local configuration file named https.conf. Depending on your workload, choose the appropriate blueprint below.

Blueprint A: Standard Non-WordPress Deployments

This block handles clean 301 redirection toward the canonical www HTTPS endpoint for standard sites.

nginx
if ($scheme = http) {
     return 301 https://www.$server_name$request_uri;
}

Blueprint B: WordPress Deployments (Front-Controller Pattern)

WordPress relies on a front-controller routing model to process dynamic permalinks. If you enforce the redirect without declaring how Nginx handles directory and file resolution, requests can break after the scheme upgrade.

Combine the 301 redirect with the try_files fallback directive:

nginx
if ($scheme = http) {
   return 301 https://www.$server_name$request_uri;
}
location / {
   try_files $uri $uri/ /index.php?q=$uri&$args;
}

---

Pipeline Comparison

Deployment Type	Core Mechanism	Routing Strategy
Standard Setup	$scheme evaluation	Direct permanent 301 redirect to canonical https://www
WordPress Setup	$scheme evaluation + try_files	301 redirect + Front-controller fallback (index.php?q=$uri&$args)

---

Step-by-Step Implementation via Webuzo UI

Keep your terminal closed. Injecting the configuration through the panel guarantees durability.

1. Authenticate to the Webuzo Enduser Panel.
2. Navigate the menu hierarchy: Web Server > Nginx > Configuration.
3. Select the Extra Configuration tab.
4. Click the right-most add action icon (represented by the + sign) to open the upload dialogue.
5. Upload your local https.conf file.
6. Click Add Record and confirm the operation returns a success toast notification.

---

Validation and Process Cycling

Once the configuration is attached, verify your ingress pipeline from the command line using curl. Inspect the raw response headers:

bash
curl -I http://yourdomain.com

You should see an explicit 301 status with the secure canonical URI in the Location header:

http
HTTP/1.1 301 Moved Permanently
Location: https://www.yourdomain.com/

If the response remains on HTTP, the running Nginx worker processes have not yet cycled their state to parse the newly mapped config block. Force a reload through the UI:

• Go to Webuzo > Services > Nginx > Restart.

Run the verification curl command again. The redirect will execute cleanly at the web server layer, cutting out unnecessary plugin overhead and securing all inbound traffic.