VVV: Intermittent NGINX 404s

Though this is primarily a “me too”, I wanted to offer a few pieces of info from the couple of hours I spent trying to get this to work (new pull of VVV, VMware Fusion on 10.11.3). First off, the 404 errors are indeed not coming from nginx in the VVV VM, they are coming from whatever is answering for .dev sites at 127.0.53.53 (which is what any .dev site now resolves to):

$ host youmakemesounhappy.dev
youmakemesounhappy.dev has address 127.0.53.53
youmakemesounhappy.dev mail is handled by 10 your-dns-needs-immediate-attention.dev.

So, given that, I tried to spend some time moving from .dev -> .localhost. As an aside, it looks like the canonical place to do this should be to change www/vvv-hosts and everything should ripple out from there, but unfortunately that’s not the only place that will need changing (the nginx config still expects to serve to hosts named *.dev, and the page of resources still lists .dev hosts). I haven’t tracked them all down, because I ran into fun with my /etc/hosts file first.

No matter what cargo cult modifications I made to /etc/hosts (which is really /private/etc/hosts) or number of times I tried to flush the DNS cache, I couldn’t get a browser on my system to reliably find any of the VVV hostnames with a .localhost suffix. I tried then switching to .vvv, thinking maybe .localhost (since it is a legit host name) could be causing problems. Finally, in one last ditch effort to get it working, and spurred on by various reports of OSX not like certain formats of hosts file, I tried removing the huge comments on each line put there by the hostmanager plugin. This seemed to work briefly. Then I found I could reliably, but temporarily get things working again if I simply added a newline at the end of the last host entry added by hostmanager.

Here’s my current thinking, with the caveat that this is based on guesswork/testing, but no real knowledge of how things are really working. This is really looking like some sort of DNS round-robinish problem with the /etc/hosts file being one of sources of info. I get the feeling that each time I touch /etc/hosts, the info in it gets added to some cache that also contains the DNS lookup results for the same hosts. So sometimes you get the /etc/hosts .dev info (192.168.50.4), sometimes you get the DNS version (127.0.53.53). And the cache of the hosts file info times out too without being refreshed automatically, so at some point if it isn’t changed, we lose the entries in it (which is why .localhost or .vvv doesn’t work over time as well). For all I know, this could be part of an in-brower cache.

Here’s another data point: out of frustration, I went back and tried DesktopServer which is an XAMP-based WP dev environment that also uses the /etc/hosts file to create .dev hosts. The hosts it creates use 127.0.0.1 and in the time I spent with it last evening, those always worked. I don’t know if localhost is therefore special cased, or whether having the same suffix in /etc/hosts and DNS was the differentiating factor.

So where does this leave this bug? It seems pretty likely to me that using .dev (w/o a 127.0.0.1) is likely to be fraught with peril. I can go back and try and root out all of the .dev mentions and instead slot in something like .vvv or .test to see if it can work in a stable fashion if you’d like. It’s also possible that another vagrant plugin (vagrant-ghost has been mentioned) could produce better formed hosts lines. I’m just concerned that /etc/hosts based names may not play as nice as they used to in the past. An alternative would be to do something like this which uses a dynamic DNS service like xip.io to do the mapping.

+1, I also had multiple vagrant’s hosts executing at the same time. I opened VirtualBox, halted everything and did a “vagrant up” of my machine and… Now it works like a charm 😃.

opening VirtualBox GUI and shutting down all the other running VMs solved my issue. Got the idea from @jeremyfelt on this thread https://github.com/Varying-Vagrant-Vagrants/VVV/issues/542

Went into VirtualBox and there was two different VMs running, I think they were conflicting one another. Shutting all down except the one I was using solved my issue.