Windows 10: Too many redirects with HTTPS

I’m running into some HTTPS problems on Windows 10 and seeing something odd.

I’ve selected Apache for my site (and tried resetting it multiple times then stopping/starting site), but my dev tools shows the server is nginx.

No clue what’s required to troubleshoot this or fix. All I know is:

  1. Local says Apache
  2. Firefox dev tools says nginx

Update: I see that BackupBuddy reports Apache. That makes me think that the redirect problems I’m getting are hitting an nginx server somewhere else?

I’ve updated the title to better reflect this issue. Consider the first two posts potentially useful symptoms.

I’ve flushed my permalinks, triple-checked that my site URL is accurate and includes https, deactivated all plugins, and yet I still get “Too many redirects” in both Firefox and Chrome on HTTPS. I’ve trusted my SSL certificate.

Firefox dev tools shows a long series of 302 directs whereas Chrome’s simply shows “failed”, but both show a “too many redirects” error.

Reviewing this thread: Fixed: 301 redirect loop on newly restored/cloned site, I as surprised to see the statement: “in order for Local to work, you need to set siteurl and home to http:// (no https !!)”. I find that very confusing…

I updated the siteurl and home options and the site does indeed load over HTTPS. However, all the resources get blocked since they’re loading over HTTP because siteurl is http://.

How can I get my local site onto HTTPS?

Any update to this? I’m constantly running into SSL/HTTPS issues with Local when importing sites via Backupbuddy.

There is a lightweight nginx reverse proxy container that sits in front of all Local sites that way every site is accessible on port 80.

This definitely shouldn’t be required. I just created a brand new site using the Custom environment with Apache, set the siteurl and home to contain https:// and didn’t run into the issue on macOS. I’ll check it out on Windows.

With that said, I know that’s not super helpful so we’ll continue digging. :slight_smile:

@mrwweb @ViscoDesign,

Does this issue pop up only when importing from BackupBuddy backups or does it happen with brand new sites created in Local?

Hey again,

Here’s a related thread with a solution from @coccoinomane: Running WP in a subdirectory nginx, wp-admin too many redirects

Sorry, I didn’t realise this was a Windows thread! But for me, on a Mac, new sites are working fine. It’s only happening with BackupBuddy sites. And it doesn’t seem to matter whether the live site was http or https to begin with. Here are the steps…

  1. Create brand new site in Local (Mac, latest)
  2. Upload importbuddy.php and BackupBuddy zip file to newly created site and start a migration
  3. Trust ssl cert, once the migration has been created
  4. Everything works fine over http, but site does not use https
  5. Try changing home_url and site_url to https, breaks site (too many redirects)
  6. Change back to http, site works again, but homepage keeps redirecting to https (which does not load assets) — despite constant clearing of cookies, htaccess and chrome://net-internals/#hsts

Pretty sure I’ve tried many variations of using http/https in importbuddy URL setting, or trusting cert before and after migration. Same result always with imported sites via BackupBuddy.

Hope this helps. Thanks!


Yes, this was a BackupBuddy site, though I haven’t used Local enough to figure out if it only impacts BackupBuddy installs.

The solution you linked to did solve my problem. I hadn’t tried it before since my site was set to use Apache and it wasn’t installed in a subdirectory…

If this is an issue, it would be really nice to have Local set it up by default.

Awesome, glad to hear!

That issue should be resolved in Local 2.1.0 :slight_smile:

Did you get this resolved? I have the same issue…

No I didn’t. I haven’t had to import another live site since, so I haven’t had much time to investigate. I’ve been busy trying to fix other Flywheel issues.

However, I will say I have been using Connect within Local and it seems to work great.

@raison @ViscoDesign,

Is the site using .dev? If so, changing the site’s domain from .dev to .local or .test may help.

Thanks Clay. That worked for one of my sites a few weeks back, so I’m hoping it wasn’t pure luck and it’ll work going forward :slight_smile:

1 Like