# Browsersync HTTPS Compatibility

**URL:** <https://community.localwp.com/t/browsersync-https-compatibility/38395>\
**Category:** Feature requests\
**Created:** [August 2, 2023, 5:59pm UTC](https://community.localwp.com/t/browsersync-https-compatibility/38395 "2023-08-02T17:59:28Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![aquamarine](https://sea1.discourse-cdn.com/flex019/user_avatar/community.localwp.com/aquamarine/32/15481_2.png) [@aquamarine](https://community.localwp.com/u/aquamarine)\
**Post date:** [August 2, 2023, 5:59pm UTC](https://community.localwp.com/t/browsersync-https-compatibility/38395/1 "2023-08-02T17:59:28Z")

</div>

This feature request is related to [Browsersync for HTTPS](https://community.localwp.com/t/browsersync-for-https/37960), so see full details there.

Essentially, Browsersync hangs when used with HTTPS in Local, e.g.

```auto
npx browser-sync start --proxy https://playground.local

```

will never resolve due to its use of https (http works fine). Editing the /private/etc/hosts file to eliminate the `::1` entry:

```auto
## Local - Start ##
# ::1 playground.local #Local Site (works if commented out)
127.0.0.1 playground.local #Local Site
::1 www.playground.local #Local Site
127.0.0.1 www.playground.local #Local Site
## Local - End ##

```

resolves the issue, but any time you start, restart, or add a new site to Local, all comments get reset, and you have to reimplement them in /private/etc/hosts manually again to use Browsersync with HTTPS.

# Solutions

1. If it doesn’t cause other issues to not add the `::1` entry to begin with, that would solve the issue.
2. If it’s possible to have the hosts file update routine preserve manually-commented-out URLs rather than rewriting everything from scratch each time, that could be helpful (though it’s still a hassle to get in there and add it once per site).

I’m not a virtual server expert (just a simple front-end developer 🤓), so there may be other options as well.