computer screen showing https address

Apache redirect HTTP to HTTPS with an .htaccess file

Key takeaways

  • Apache can redirect HTTP to HTTPS with either a VirtualHost rule or an .htaccess rule.
  • The redirect only works if SSL is already installed and HTTPS is already working.
  • .htaccess is useful when you do not have server access, while VirtualHost is usually the better option when you do.
  • Testing matters because redirect loops, cached 301s, and CDN or proxy conflicts can break the redirect.

Redirecting HTTP to HTTPS is one of the simplest ways to improve security, browser trust, and URL consistency. It also helps make sure visitors and crawlers land on the secure version of your site instead of splitting traffic between two protocols. 

This article focuses on the .htaccess method because it is a practical option for many Apache environments. It also covers when VirtualHost makes more sense, what to check before you force HTTPS, and how to avoid the most common redirect problems.

Ready to get started?

Find the right SSL certificate for your server or site.

Why redirect HTTP to HTTPS

Redirecting HTTP to HTTPS protects data in transit, avoids browser warnings on insecure pages, keeps users on the trusted version of the site, and supports a cleaner canonical URL structure for search engines.

If your site already has a working certificate, leaving HTTP active without a redirect creates unnecessary inconsistency. Some users will land on the secure version, others won’t. A permanent redirect fixes that.

What you need before you force HTTPS

Before you add a redirect rule, confirm a few basics first.

SSL must already be working

The HTTPS version of the site should already load correctly with a valid SSL or TLS certificate. Don’t force HTTPS first and hope the certificate issue sorts itself out later.

Apache must allow the method you plan to use

If you plan to use .htaccess, make sure:

  • mod_rewrite is enabled
  • Apache allows .htaccess overrides where the site runs

If you plan to use VirtualHost instead, make sure you have access to the site configuration files.

Back up the current configuration

Before editing .htaccess or an Apache config file, create a backup. A bad rule can block access fast, so back up before making changes.

Test the config after changes

Before restarting or reloading Apache, run a config test:

This one check can save time.

Apache redirect HTTP to HTTPS with an .htaccess file

If you do not have access to the main Apache config files, .htaccess is often the fastest way to redirect HTTP to HTTPS.

Add this rule near the top of your site’s .htaccess file:

This rule does three things:

  • Turns the rewrite engine on
  • Checks whether the current request is using HTTP
  • Sends the request to the same host and URI over HTTPS with a permanent 301 redirect

Why use a 301 redirect

A 301 tells browsers and search engines that the change is permanent. That is usually the right choice when moving the site from HTTP to HTTPS for good.

Use VirtualHost when you have server access

If you can edit Apache site configuration files, VirtualHost is usually the better option. It is cleaner and more efficient than relying on .htaccess.

A basic redirect in the *:80 VirtualHost can look like this:

This method works well when you:

  • Control the Apache config
  • Want the redirect managed at the server level
  • Want to avoid putting the redirect in .htaccess

You should also already have a working *:443 VirtualHost configured for HTTPS before using this method.

.htaccess vs. VirtualHost

Use .htaccess when you:

  • Don’t have access to Apache site config files
  • Need a quick, site-level change
  • Have a hosting environment relies on .htaccess overrides

Use VirtualHost when you:

  • Control Apache config files
  • Want the cleaner and more efficient option
  • Want to keep redirect rules out of the document root

Both methods can work; the better choice usually comes down to the level of access you have.

How to force HTTPS in Apache without breaking the site

A redirect rule is simple, the environment around it is where problems usually start.

Test HTTPS first

Load the HTTPS version of the site directly before enabling the redirect to confirm it is working.

Keep canonical host rules clean

If the site also redirects www to non-www, or the other way around, make sure the redirect path is clear. Too many layered rules can create chain redirects or loops.

Check subdomains carefully

Subdomain behavior needs to be confirmed before you roll out a site-wide redirect. A rule that works for the main domain may not be what you want for every subdomain. 

Watch for CDN and load balancer conflicts

If traffic passes through a CDN, reverse proxy, or load balancer, Apache may not see the original protocol the way you expect. That can lead to redirect loops or failed conditions if the proxy handles HTTPS separately. 

Common redirect problems and fixes

Too many redirects

This usually means another rule is fighting your HTTPS redirect. Check:

  • .htaccess
  • Apache VirtualHost files
  • CDN or proxy settings
  • App-level redirect logic

Make sure nothing is redirecting HTTPS back to HTTP.

Redirect does not happen at all

Check whether:

  • mod_rewrite is enabled
  • .htaccess overrides are allowed
  • The rule is in the correct file and location

Browser still shows old behavior

Browsers cache 301 redirects aggressively. Test in an incognito window or clear cache before assuming the rule failed.

Mixed content warnings

A redirect does not automatically fix hard-coded http:// asset URLs. After the redirect works, review scripts, images, stylesheets, and embedded resources for mixed content problems. 

Apache config errors

Run this before restarting or reloading Apache:

Then reload or restart Apache only after the syntax check passes.

How to test the redirect

You can test in a browser, but command-line verification is cleaner.

Use:

You should see a:

  • 301 response
  • Location header pointing to the HTTPS version

That confirms Apache is sending HTTP traffic to the secure URL.

Should you add HSTS too?

HSTS can strengthen HTTPS enforcement after the redirect is already working. It tells browsers to prefer HTTPS automatically for future visits.

A common header looks like this:

Only add HSTS after:

  • HTTPS works everywhere
  • Subdomain behavior is confirmed
  • Mixed content issues are fixed

Browsers cache HSTS aggressively, so it is worth being careful here.

Apache redirect HTTP to HTTPS FAQs

You can force HTTPS in Apache with either a VirtualHost redirect or an .htaccess rewrite rule. If you do not have server config access, .htaccess is usually the practical option.

Make sure SSL is already installed and working, then add a redirect from the HTTP version of the site to the HTTPS version.

Use .htaccess when you do not have access to the main Apache config. Use VirtualHost when you do, since it is usually cleaner and more efficient.

That usually means another rule, proxy, CDN, or app setting is conflicting with the HTTPS redirect.

You need mod_rewrite for the rewrite-based .htaccess method. A VirtualHost redirect can use Apache’s redirect directive instead.

Yes, but only after HTTPS is fully working and mixed content or redirect issues are already fixed.

Apache redirect HTTP to HTTPS next steps

Redirecting HTTP to HTTPS in Apache is straightforward when SSL already works and the redirect is placed in the right layer.

Start by testing the HTTPS version of the site first, then choose .htaccess or VirtualHost based on the access you have.

Liquid Web gives teams hosting environments built for secure configuration, cleaner server management, and dependable infrastructure. Explore our reliable hosting solutions and dedicated server options built for environments where security and control both matter.

Ready to get started?

Find the right SSL certificate for your server or site.

Related articles

Wait! Get exclusive hosting insights

Subscribe to our newsletter and stay ahead of the competition with expert advice from our hosting pros.

Loading form…