Roots Discourse

Browsersync stuck loading when proxying Trellis local dev site

Hi. I’m trying to get browsersync to work with the local (Vagrant box) version of my site, and I think something inside of Trellis’s config is blocking it.

I’ve got the Trellis site deployed on a Kinsta staging environment, and if I point browsersync to that domain as a proxy, it works perfectly on local and external addresses (so browsersync itself is working). I can also vagrant up and access the local https://mysite.test domain of the development site, no problem.

But when I then try to proxy browsersync to https://mysite.test and access it on https://localhost:8181 (custom port I mapped), I get a blank window that tries to load endlessly yet (apparently) never gets a response from the server.

What I’ve checked (including a few possible fixes from this thread):

  • The browsersync server does launch on localhost:8181 and the external IP 192.168.x.x:8181. A netcat scan of each shows that I can connect with TCP (for example, nc -vn 8181). It’s definitely browsersync running there, since as soon as I stop the server with ^C, the ports close again.
  • The access logs inside the Vagrant box do not show any access attempts when I try to load the browsersync’d site.
  • Browsersync’s own UI loads fine on localhost:3001.
  • Browsersync itself doesn’t report any problems on the command line or in the UI — but also doesn’t show any browser connections.
  • Turning off the custom port 8181 and trying browsersync’s default localhost:3000 doesn’t change anything.
  • Turning off the macOS firewall doesn’t change anything
  • Trying to proxy mysite.test without https doesn’t work either.
  • group_vars/development/wordpress_sites.yml has the mysite.test domain set for site_hosts -> canonical
  • I’ve tested Chrome, Safari, and Firefox Dev Edition. Chrome & Safari both do the endless loading thing. Firefox shows a self-signed cert error that appears to come from browsersync, then if I accept & continue, it too “proceeds” to endless loading.

Here are the options that are currently passed to browsersync’s init method:

const serverConfig = {
	proxy: "https://mysite.test",
	port: "8181",
	logLevel: 'debug',

My best guess right now is that the Vagrant server accepts the connection from browsersync, but refuses to send back any site content because of some config within Trellis.

I compared the headers coming from my Kinsta staging site (that Browsersync worked with) and mysite.test on Vagrant, and these values are being set on mysite.test but not on Kinsta:

  • content-security-policy: frame-ancestors 'self'
  • x-frame-options: SAMEORIGIN
  • x-xss-protection: 1; mode=block

Is one of those what’s blocking browsersync, or a corresponding internal setting in nginx? I’m past the limit of my knowledge here… Any ideas what I can try?

I also encountered an CORS-related BrowserSync issue in the past - could this help you?:

What Sage theme version are you using? If you are using Sage 9 you may find the Sage 9.x update branch interesting which fixes a ton of build/watch issues:

Alas, no luck adding the CORS option :frowning:. That kind of makes sense, though… it looks like that adds a CORS header to the response from Browsersync, while in my case the issue seems to be between the Vagrant box and Browsersync — before anything browser-related.

I’m actually not using Sage. This project is based on WP Rig, which I think is more along the lines of how Sage 8 worked. (Particularly using a Gulp pipeline.)

But, I think I’ll try the 9.x update branch you mentioned just as a sanity check. To be continued…

This topic was automatically closed after 42 days. New replies are no longer allowed.