Browsersync + gulp problem with .local

Support
1

Hi,
So, first of all, one of my local websites began throwing 502 Gateway Error when trying to load it. Just one. When I changed its domain from .dev to .local, it continued to work fine. Any clue on what could be going on? I checked the /var/log/nginx/error.log and it showed the following error:

upstream sent too big header while reading response header from upstream, client: 127.0.0.1, server: site_domain, request: “GET /contest HTTP/1.0”, upstream: "fastcgi://unix:/var/run/php-fpm.sock:

Which I kind of know how to fix but I really dislike the idea of having to manually change the nginx configuration manually to solve a specific bug.

Second thing is kind of a bug. After the update, I changed most of my local sites domains from .dev to .local, as is now encouraged by the 2.1.0 update. I usually develop custom themes and my workflow relies heavily on gulp + browsersync but since the update I noticed that browsersync is extremely slow when reloading, which never happened before.

Well, after a short research I found out that apparently there are problems when using browsersync on a website with .local domain on Mac:
https://stackoverflow.com/questions/24807786/browsersync-extremely-slow

So I guess I’ll need to go back to .dev domains and manually fix my nginx issue. Do you have any suggestion regarding the .local domain thing with browsersync?

2 Likes
2

I’m having the same performance issue. I’d never have thought that it could be because of the “.local” domain. Thanks for the link!

When I change the domain from ".local "to “.dev”, the site won’t load. Would you mind sharing in more details how you fixed that?

3

Actually, I couldn’t fix it. I thought it was some fastcgi buffer problem but changing the configuration at /etc/nginx/nginx.conf didn’t solve it. I resorted to just use a subdomain like dev.mydomain.com with which everything just works.

But I would really like the Flywheel staff to start a conversation about this. Maybe look around for better options or suggest subdomains instead. I love how the UI makes it ridiculously easy to set up local environments but encouraging users to use .local knowing what random and hard-to-debug problems can appear with the .local domain isn’t good design.

4

I don’t have a solution here, I’m having the same problem, but I can maybe shed some light on why they moved away from .dev

Don’t know what the solution is but Flywheel definitely needs to fix this, if only just on the macOS version.

5

@Baltar, changing to .dev worked for me. Make sure you change it both in Local and in your Browsersync/gulp config.

6

FWIW, I had the same issue with Browsersync not working with .local domains, and .dev not working in Chrome, so I tried some other reserved TLDs, and discovered that using .test resolves both Browsersync and Chrome issues in my situation. Hopefully that helps someone else!

2 Likes
7

Hello! So, a little late to the party, but hopefully I can offer a little clarity on why this is happening and how to solve it -

  • Issue 1 - .dev domains - .dev domains are now on the HSTS Preload list, which means that browsers will expect HTTPS traffic only and won’t load via HTTP. You can create a self-signed certificate, but in the long term is most likely best to use something else

  • Issue 2 - BrowserSync being slow - More DNS stuff, woo! .local, the default domain for Local sites, is shared with Bonjour on Macs. Long story short, Bonjour is completing the IPv6 lookup for the proxy address before the IPv4 (which resolves to your site)

The Solution - Easy. Use a subdomain, something along the lines of dev.mysite.com. No Bonjour conflicts, no security hissy-fits, and since you’re still using a registered TDL (not something like .test), you can be sure that features like OAuth redirects will work properly.

Hope this helps anyone reading!

1 Like
8

Hi, when I try the dev.mysite.com subdomain it seems to work fine initially and browsersync works a lot faster, but then when I click the hyperlinks it takes me off to the live .com site. Does this happen for you?

9

@iWildman1 @paulca55,

One thing you can do is enable the IPv6 Loopback option under Local » Preferences » Advanced. This will create an IPv6 entry for the Local site domain and eliminate the DNS delay.

Using that, you should be able to use .local fine.

1 Like
10

@paulca55 It may be to do with the site_url in your wp_options table, that’ll adjust where your hyperlinks redirect! As Clay said though, using IPv6 won’t try to connect to Bonjour so should work just as quickly!

1 Like
11

Thanks that’s worked a treat :grinning: