If your Plesk server is still serving pages over plain HTTP, you're exposing visitors to security risks and leaving SEO value on the table. Plesk force HTTPS redirect is one of the first configurations every server administrator should lock down after installing an SSL certificate. Whether you're running Apache, Nginx, or Plesk's combined proxy mode, this guide walks you through every method — from the one-click UI option to manual config edits — and shows you how to fix the most common problems like redirect loops and mixed content errors.
💡 None of these worked? Skip the guesswork.
Get Expert Help →Enable HTTPS Redirect via Plesk UI (Easiest Method)
Plesk provides a built-in toggle to force HTTPS across an entire domain. This is the fastest approach and works for most standard setups without touching any config files.
Open your browser and go to https://your-server-ip:8443 or your Plesk hostname. Log in with your administrator credentials.
From the left menu, click Websites & Domains. Find the domain you want to redirect and click on it to expand its options.
Click Hosting & DNS, then select Hosting Settings for the target domain.
Scroll down to the Security section. Check the box labelled Permanent SEO-safe 301 redirect from HTTP to HTTPS. Click OK or Apply to save.
Open a terminal and run:
curl -I http://yourdomain.comYou should see a 301 Moved Permanently response with a Location: https://yourdomain.com/ header. If you see this, the redirect is active.
Note: If the SSL certificate is not yet installed on the domain, the redirect toggle will either be greyed out or will cause a browser error. Install the certificate first via SSL/TLS Certificates in Plesk before enabling the redirect.
In Plesk, go to Websites & Domains → click on the domain → Apache & Nginx Settings.
There are two text boxes: one for HTTP (port 80) and one for HTTPS (port 443). Place the redirect in the HTTP box.
return 301 https://$host$request_uri;This is the cleanest Nginx redirect. It returns a 301 immediately without going through regex processing, making it slightly faster than a rewrite rule.
Click OK. Plesk will validate and reload Nginx automatically. Test with:
nginx -t
curl -I http://yourdomain.comManual Nginx Server Block (Advanced)
If you manage the Nginx configuration outside of Plesk (e.g., on a custom server setup), add a dedicated server block for port 80:
server {
listen 80;
listen [::]:80;
server_name yourdomain.com www.yourdomain.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name yourdomain.com www.yourdomain.com;
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
# ... rest of your site config
}Reload Nginx after any manual edit:
nginx -t && systemctl reload nginxFix Redirect Loops in Plesk
A redirect loop is one of the most frustrating outcomes of a misconfigured HTTPS redirect. The browser shows an error like ERR_TOO_MANY_REDIRECTS and the page never loads. Here are the most common causes and fixes in Plesk environments.
Cause 1: Apache Behind Nginx Proxy Using Wrong Condition
As covered above, when Nginx proxies to Apache, Apache's %{HTTPS} variable is always off. If Apache's .htaccess redirects based on %{HTTPS}, it redirects every request — including the HTTPS ones already forwarded by Nginx — creating an infinite loop.
Fix: Replace RewriteCond %{HTTPS} off with RewriteCond %{HTTP:X-Forwarded-Proto} !https as shown in the Apache section above.
Cause 2: Duplicate Redirects in Both Nginx and .htaccess
If the Plesk UI redirect is enabled AND there's also a redirect rule in .htaccess, requests can chain unpredictably.
Fix: Use only one method. Either use the Plesk UI toggle or the .htaccess rule — not both. To check what Plesk has auto-configured:
cat /var/www/vhosts/system/yourdomain.com/conf/vhost.confCause 3: WordPress or CMS Forcing HTTP in Site URL
If WordPress's siteurl or home settings in the database still point to http://, the CMS will redirect HTTPS requests back to HTTP, conflicting with the server-level HTTPS redirect.
Fix: Update the WordPress URLs via WP-CLI or the database:
wp option update siteurl 'https://yourdomain.com'
wp option update home 'https://yourdomain.com'Cause 4: Plesk Let's Encrypt Redirect Active Plus Manual Rules
Let's Encrypt in Plesk sometimes activates its own redirect rule. Check for conflicts in:
/var/www/vhosts/system/yourdomain.com/conf/vhost_ssl.confRemove any duplicate return 301 or RewriteRule lines you find alongside the Plesk-managed ones.
Cause 5: CDN or Load Balancer Terminating SSL
If Cloudflare or another CDN terminates SSL at the edge and forwards HTTP to your origin, your Plesk server sees all traffic as HTTP and redirects it — even traffic that arrived at the CDN over HTTPS. This causes an infinite loop.
Fix: In Cloudflare, set SSL mode to Full (Strict) and disable the server-level HTTP-to-HTTPS redirect if the CDN handles it. Alternatively, trust the X-Forwarded-Proto: https header from Cloudflare in your redirect condition.
Fix Mixed Content Errors After Enabling HTTPS
Once HTTPS redirect is working, browsers may still show a padlock with a warning — or break page styles — because some resources on the page are still loading over HTTP. This is called a mixed content error.
Identify Mixed Content
Open the browser's Developer Tools (F12) → Console tab. Look for errors like:
- Mixed Content: The page was loaded over HTTPS, but requested an insecure resource 'http://...'
- Blocked images, scripts, or stylesheets
You can also use an online tool like Why No Padlock to scan your URL for mixed content.
Fix Mixed Content in WordPress
The easiest fix is the Really Simple SSL plugin, which rewrites HTTP URLs to HTTPS automatically. For a manual fix, use Search & Replace in the database:
UPDATE wp_options SET option_value = REPLACE(option_value, 'http://yourdomain.com', 'https://yourdomain.com');
UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://yourdomain.com', 'https://yourdomain.com');
UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, 'http://yourdomain.com', 'https://yourdomain.com');Add HTTP Strict Transport Security (HSTS)
Once you're confident HTTPS is working correctly, add an HSTS header to tell browsers to always use HTTPS — even before making the first request. In Plesk's Nginx Additional Directives (HTTPS box):
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;Warning: Once HSTS is set with preload, it is very difficult to revert. Only add this when you are certain HTTPS will remain active permanently on all subdomains.
Fix Hard-Coded HTTP URLs in Application Config
Many CMS platforms and apps store the base URL in a config file or environment variable. Check:
- WordPress:
wp-config.php— look forWP_HOMEandWP_SITEURLconstants - Laravel:
.env—APP_URLshould behttps://yourdomain.com - Joomla:
configuration.php—$live_sitevariable - Drupal:
settings.php—$base_urlvariable
Update each to use the https:// scheme, then clear your application cache.
If your Plesk server setup is complex or you're managing multiple domains with mixed content issues across stacks, the team at managed server management from CloudHouse Technologies can audit your configuration and resolve HTTPS redirect issues without downtime.
FAQs
Why is my Plesk HTTPS redirect not working even though SSL is installed?
The most common reasons are: the SSL certificate is installed but the domain's Hosting Settings don't have the redirect toggle enabled; or there's a conflicting rule in .htaccess that's redirecting back to HTTP. Check both the Plesk UI redirect option and your .htaccess file. Also verify the certificate covers the correct domain (including www) using openssl s_client -connect yourdomain.com:443 -servername yourdomain.com.
How do I force HTTPS for all domains on a Plesk server at once?
Plesk doesn't have a global "force HTTPS for all domains" toggle in the UI. You can use the Plesk CLI to loop through all subscriptions: plesk bin subscription --list gives you all domains. Then use Plesk's API or the plesk bin domain command to set hosting preferences per domain. Alternatively, configure the redirect at the Nginx level in the server-wide config rather than per-domain.
My Plesk redirect works but mixed content errors still appear — what should I check?
Mixed content happens when the HTML page is served over HTTPS but embedded resources (images, CSS, JavaScript, fonts, iframes) are referenced with http:// URLs. Start by checking the browser Console for specific blocked resources. Then search your CMS database and config files for hard-coded http:// references. For WordPress, the Really Simple SSL plugin or a database search-and-replace (WP-CLI: wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --all-tables) will fix the majority of cases.
How do I fix ERR_TOO_MANY_REDIRECTS on a Plesk server with Nginx and Apache?
This almost always means both Nginx and Apache are redirecting, or Apache is redirecting based on %{HTTPS} off while running behind the Nginx proxy. Because Nginx terminates SSL and forwards plain HTTP to Apache internally, Apache always thinks the connection is HTTP. Fix it by using RewriteCond %{HTTP:X-Forwarded-Proto} !https in your .htaccess instead of RewriteCond %{HTTPS} off. Also disable any duplicate Plesk UI redirect if you're managing it manually.
Does forcing HTTPS in Plesk affect email deliverability or mail server settings?
No — the HTTP-to-HTTPS redirect only affects web traffic on ports 80 and 443. Email services in Plesk (Postfix/Dovecot/MailEnable) run on separate ports (25, 465, 587, 993, 995) and are not affected by web redirect rules. However, if you have web-based email forms or SMTP relay scripts that reference your domain via http://, those should be updated to https:// to avoid mixed content warnings on your contact or mailing pages.
Forcing HTTPS in Plesk is a foundational security step that protects your users' data, prevents browser security warnings, and gives your site a stronger signal in search rankings. The Plesk UI toggle is the simplest route, but understanding the Apache .htaccess and Nginx directive approaches gives you the flexibility to handle edge cases, exclude paths, and troubleshoot loops without guessing. Once the redirect is solid, follow up by replacing any remaining HTTP resource URLs to eliminate mixed content warnings and consider adding an HSTS header to lock in HTTPS for returning visitors permanently.