Browsersync for HTTPS

[aquamarine]

Issue Summary

Browsersync used to work with HTTPS, but stoped working a few weeks ago.

So, for instance, I had a localwp site at https://playground.mydomain.test, and was able to run:

browser-sync start --proxy https://playground.mydomain.test

and access the site at https://localhost:3000 (after accepting the cert warning).

But recently, that no longer works. I’m able to access https://playground.mydomain.test like before, but https://localhost:3000 spins and spins without resolving.

The only fix that’s worked has been to change the site to http://playground.mydomain.test, then run browser-sync at that non-https version: then everything works fine at http://localhost:3000. This is workable, but a hassle, as any older projects I do work on, I’m needing to replace https with http in the database before I can do work. Plus, some sites are getting ugly mixed content warnings since they rely on 3rd party https content within them. Using HTTPS everywhere, local through staging through prod, works best for my workflow.

Is there any way to get https://localhost:3000 working again?

Troubleshooting Questions

• Does this happen for all sites in Local, or just one in particular?
  All of them, old or newly created. I tried different suffixes too, like https://browsersync.something-new.net, but still have this issue. Note also that running browser-sync start --https --proxy https://playground.mydomain.test with the --https flag doesn’t change anything. Also, browser-sync start --proxy https://localwp.com works fine for your production URL, so it’s not an issue with browser-sync and SSL per se, it’s specifically when it’s a local site served via localwp. This happens whether I’ve not trusted the cert, or if I’ve trusted it (including within keychain).

• Are you able to create a new, plain WordPress site in Local and access it in a Browser?
  Yes, everything works great when accessing localwp’s site URL directly, just not via Browsersync’s HTTPS URL.

Replication

Describe the steps that others can take to replicate this issue. If you have screenshots that can help clarify what is happening, please include them!

1. Create a new site on localwp.
2. Install browser-sync if you don’t have it installed already.
3. Run browser-sync start --proxy https://whatever-your-site-is.test.
4. Open https://localhost:3000 and notice that it never resolves, just spins on a blank screen.

System Details

• Which version of Local is being used?
  Current latest, 7.0.2+6395.

• What Operating System (OS) and OS version is being used?
  macOS Ventura 13.4.1 (22F82)

• Attach the Local Log.
  This is upon startup of the server, not sure if it’s helpful:

{"thread":"main","class":"Process","process":"mysql","level":"warn","message":"2023-07-07T13:54:47.191520Z 0 [System] [MY-010116] [Server] %%resourcesPath%%/lightning-services/mysql-8.0.16+6/bin/darwin/bin/mysqld (mysqld 8.0.16) starting as process 49369","timestamp":"2023-07-07T13:54:47.438Z"}
{"thread":"main","class":"Process","process":"mysql","level":"warn","message":"2023-07-07T13:54:47.193991Z 0 [Warning] [MY-013243] [Server] --character-set-server: The character set UTF8MB3 is deprecated and will be removed in a future release. Please consider using UTF8MB4 instead.","timestamp":"2023-07-07T13:54:47.438Z"}
{"thread":"main","class":"Process","process":"mysql","level":"warn","message":"2023-07-07T13:54:47.194552Z 0 [Warning] [MY-010159] [Server] Setting lower_case_table_names=2 because file system for %%site.runData%%/mysql/data/ is case insensitive","timestamp":"2023-07-07T13:54:47.439Z"}
{"thread":"main","class":"Process","process":"mysql","level":"warn","message":"2023-07-07T13:54:47.425230Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.","timestamp":"2023-07-07T13:54:47.439Z"}
{"thread":"main","class":"Process","process":"mysql","level":"warn","message":"2023-07-07T13:54:47.438209Z 0 [System] [MY-010931] [Server] %%resourcesPath%%/lightning-services/mysql-8.0.16+6/bin/darwin/bin/mysqld: ready for connections. Version: '8.0.16'  socket: '%%site.runData%%/mysql/mysqld.sock'  port: 10045  MySQL Community Server - GPL.","timestamp":"2023-07-07T13:54:47.439Z"}```

[aquamarine]

Quick note that this is also the case for a Sage template I’m working on for a client: I’ve had to change their config file to use http rather than https and find/replace the URL in the database so that the Sage development server will work (otherwise I get an “Error occurred while trying to proxy: localhost:3000/” error). The common thread here is that I can only proxy http versions of URLs for my build tools, not the https version as I’d like.

[Nick-B]

Hi @aquamarine

Thank you for all of your detail here. I think we’ve seen similar issues with Browsersync in the past, but as far as I know, there isn’t an exact fix. As Ben noted below on a similar thread, it can be finicky at best.

Browsersync will not load localhost:3000

Hey @irenehardy – Thanks for those extra details. It’s hard to know for sure what’s going on without seeing actual errors within the Browser console, but one thing I notice is that the gulpfile.js config is using https as opposed to regular http. My guess is that Browsersync is having issues connecting over HTTPS to the Local site. I know that it’s possible to get Browsersync to work with an HTTPS backend, but I’ve always felt that it’s been finicky and more trouble than it’s worth. As a start…

[aquamarine]

Thanks @Nick-B; yeah, I had seen that thread before posting. I just wonder why it was working for over a year for me, and then stopped working to the point I need to port all my old projects over to http

[Nick-B]

Were there any updates to your machine, Local, or the site’s configuration, etc that could have happened around the time that it changed?

[aquamarine]

Not that I know of. Security patches automatically install on my Mac, but I don’t recall getting a notice about an update occurring soon before the issue happened—that would have stood out in my mind as a possible reason.

Could running LocalWP’s SSL>Trust functionality on one site affect the SSL certs of all sites on the LocalWP install? I tried that a while ago and had issues, decided just to deal with clicking the “continue to site” warning, but didn’t notice this BrowserSync issue right away after experimenting with that.

[Nick-B]

Following up here! I checked with our team and the hunch is that something may have changed in the browser (Chrome, Safari, Firefox…) that doesn’t like the cert or maybe just isn’t compatible with Browsersync.

Accepting one cert wouldn’t affect all other Local certs on your machine since the certs are site-specific.
Once the cert is trusted, you might still need to run a search and replace in the DB to remove references to the HTTP version of URLs. This goes into that a bit - SSL in Local - Local

We aren’t certain about the root cause here but aren’t aware of any Local changes that would have impacted this.

[aquamarine]

Hey @Nick-B , thanks for following up. This is still causing issues for me (even after doing a find/replace of http to https in the database, which I had done previously as well), but I think next I’ll try uninstalling and re-installing Local to see if maybe that solves this (can’t do it this week though as I’ve got too much to do in Local with ongoing projects). Thanks again for following up!

[Nick-B]

No problem @aquamarine! Thank you for the follow up. Happy Developing

[aquamarine]

I reinstalled LocalWP, which didn’t work… but, I was able to get it working if I edit my /private/etc/hosts file and comment out the first line LocalWP adds:

## Local - Start ##
# ::1 playground.mydomain.test #Local Site (works if commented)
127.0.0.1 playground.mydomain.test #Local Site
::1 www.playground.mydomain.test #Local Site
127.0.0.1 www.playground.mydomain.test #Local Site
## Local - End ##

Everything works great with that one line commented out. My guess is it’s some sort of infinite redirect loop between ::1 and 127.0.0.1. I can comment the extra ::1 entry manually for now, but longterm I imagine that’ll get cumbersome since LocalWP may add it back in. Do you know a way around this?

[Nick-B]

I haven’t tested your workflow, but have you noticed it getting added back in yet? Or any other interruptions since your change?

[aquamarine]

It looks like any time you start a server, restart a server, add a new local site, etc., it must regenerate those hosts file entries, because they all get uncommented for every site that I have in local. I’ve just been keeping the hosts file open and re-commenting them whenever I perform one of these actions, which I only need to do maybe a couple times a day.

(btw I wonder if it’d be easy to replicate the issue on your end if you have npx? You’d just run npx browser-sync start --proxy https://your-site.local on any site that’s available via HTTPS and watch it hang, then re-run that command after commenting the appropriate line out in the hosts file to see it start working again.)

[Nick-B]

I’ve checked with the team but there isn’t any workaround we have handy to provide that would get around what you’re running into. It’s really just a limitation of using Local in this way that is a bit unavoidable. I did some searching and saw that someone created a Feature Request related to this some years back, but it never got any traction.

[Implemented] Add ::1 to all host file entires by default to speed up Browsersync

I know a number of people are running into issues using Browsersync with the .local domain (it runs horrendously slowly), apparently it’s to do with the IP6 tags and the time it takes to look up the IP each time before the refresh. MAMP doesn’t suffer from this problem because every time you add a new site it automatically adds a ::1 reference as well as the local IP to bypass the lookups. So on MAMP we have ::1 domain.local 127.0.01 domain.local Flywheel does this 127.0.01 domain.local 1…

If you wanted you could create a new Feature Request for others to vote, comment, and follow for updates. We often check these for future enhancements to the app.

[aquamarine]

Sounds good, thanks for your help!

Feature request opened.

[aquamarine]

btw I realized I can just not enter my password at the prompt to update the hosts file, and my changes will stick with the warning “could not update hosts file.” So, only every once in a while when I add a brand new site to Local will I have to enter my password to have it add new records (which will regenerate everything else, too), and then go back in and comment some things out—that’s totally workable for me