Vvv: Intermittent NGINX 404s
I just booted up a new instance of vvv.
Everything works. Then a few minutes later I get an NGINX 404 screen on everything ~ vvv.dev, src.wordpress-develop.dev. Then a few minutes later 200s and everything is fine. This experience loops.
I can restart nginx to fix the problem, but it recurs.
On Mac OS X 10.11.2, VirtualBox 5.0.12 r104815, Vagrant 1.7.4.
This may be a dupe of #807, but wanted to make a robust bug report for this.
ericandrewlewis
All 19 comments
Thank you, I have the exact same issue - also on Mac OS El Captain - install of both os and vvv is 2 Weeks old (virtualbox).
I run custom php scripts, one is aTCPDF script that outputs a PDF for inline display in the Web browser, the other was a simple phpinfo() file for testing this issue.
Both sometimes work fine, most of the time i get a 404 error - when I checked nginx access.log, the 404 failures did not even get logged there or in error.log. Although error.log did show some older errors about connection timeouts - not sure if this was XDebug related.
When i refresh the browser several times (5-10 plus, sometimes more) it sometimes works again, other times i have to wait out some time for it to work again.
Makes XDebug debugging impossible.
I tried the advice found when googling nginx php 404 errors but nothing helped.
Are there any log files I can check? Advice?
joe15000
on 23 Jan 2016
I am not sure about OS X but on win Virtualbox 5.x is pretty bad. Maybe you could test using vb 4.x
cfoellmann
on 24 Jan 2016
Weeeeird.
| when I checked nginx access.log, the 404 failures did not even get logged there or in error.log
This makes me think a network conflict could be catching those requests and routing them to a different spot. Maybe a built in El Capitan service?
It would be especially interesting to know if this surfaced for non .dev domains. We've known for a bit that we should switch to .local instead.
jeremyfelt
on 3 Feb 2016
Don't know if this helps or makes finding a solution worse - but when I shut down (vagrant halt) the mac and tried again the next day, it worked. I am not too familiar with vagrant - could it have updated something on the next vagrant up? Not sure if that is the case.
Have not had issues since. If there is anything I can check out to help, please let me know.
joe15000
on 3 Feb 2016
So, I also have no log entries. More info on #807.
My VM hosts file (excluded IPv6):
127.0.0.1 localhost
127.0.1.1 vvv vvv
127.0.0.1 vvv.dev # vvv-auto
127.0.0.1 local.wordpress.dev # vvv-auto
127.0.0.1 local.wordpress-trunk.dev # vvv-auto
127.0.0.1 src.wordpress-develop.dev # vvv-auto
127.0.0.1 build.wordpress-develop.dev # vvv-auto
Shouldn't 127.0.1.1 vvv vvv really be 127.0.0.1 vvv vvv?
raulillana
on 21 Feb 2016
Shouldn't 127.0.1.1 vvv vvv really be 127.0.0.1 vvv vvv?
I'm not entirely sure if that matters too much. More learning to do. :)
It seems that El Capitan is appearing as a common thread. I may need to upgrade and join the confusion to help troubleshoot. :tada:
It would be helpful for someone to change their configuration to use the .localhost or .test suffix instead to see if this is really #583 finally rearing its head.
jeremyfelt
on 21 Feb 2016
I just tried changing it, but no results or changes. It seems like it works till you hit a new URL you didn't visit in the past, so maybe has something to do with memcached? The memcached.log is also empty. :\
raulillana
on 21 Feb 2016
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.
dnblankedelman
on 1 Mar 2016
My solution was to update nginx config file via ssh, and turn sendfile off.
Hope this helps. :)
raulillana
on 1 Mar 2016
I'm having exactly the problem @dnblankedelman describes. Nothing I try works. I can vagrant up/down/halt/disco all I want, and my hosts file has entries for all the VVV sites.
thinkhuman
on 20 May 2016
I am running a fresh install of VVV (On OS X El Capitan) using the exact method specified in the instructions. It all works well the first time. However when I do a vagrant halt and then a vagrant up I get 404's at vvv.com and all of the other start pages. I should note that despite this vagrant ssh still works. I should also note that those pages load fine the first time.
@jeremyfelt : I've tried looking all over. How can I fix this. I am 100% happy to start over, I just want to know how to change the TLDs from the beginning (to see if that's the issue) or do whatever else is recommended. Very new to github issues. Sorry if I've broken etiquette. But I am here to offer my services as a guinea pig. I will try setting it up with whatever modifications necessary, just need guidance. It seems to me, making VVV work on a fresh OS X with El Capitan following the instructions listed would be helpful.
Lastly, I have created a Gist of the output see when running vagrant up
ercfre
on 13 Jul 2016
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
joannaong
on 29 Jul 2016
AS @joannaong mentions, opening VirtualBox GUI and removing/shutting down all other running VMs solved the issue for me too.
Thank you !
fearlex
on 10 Aug 2016
As another data point, I too am seeing intermittent nginx 404s on my VVV projects such as http://myproject.dev (which I've confirmed is in my /etc/hosts file.) What seems to be different about my setup is that I'm using VMware Fusion (v8.1.1) and I'm on Mavericks (10.9.5) still. The problem is definitely not El Capitan or Virtualbox specific and continues to persist. I've also verified that there is definitely only one VM instance running in the Fusion GUI.
beporter
on 17 Aug 2016
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.
mikeallen3
on 21 Oct 2016
+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 :).
ghostmou
on 25 Dec 2016
sorry im new here, i wonder why i cant access vvv.dev after vagrant up was finish. im using centos 7 and everything was fine because im follow every step from youtube (https://www.youtube.com/watch?v=8jC4yR5mZvc) but when i open the browser i cant access vvv.dev please help me
sukilsun
on 3 Jan 2017
It doesn't appear that anybody has encountered this previous, but regarding multiple VMs:
- You only need one instance of VVV
- A single instance of VVV can host many, many separate sites
- Individual sites can be disabled to save time using the
skip_provisioning: trueflag
tomjn
on 3 Nov 2017
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
![lock[bot] picture](https://avatars.githubusercontent.com/in/6672?v=4&s=40)
lock[bot]
on 22 Feb 2020
Related issues
pvanbavel
路
4Comments
timichango
路
3Comments
rwrobe
路
4Comments
dingo-d
路
3Comments
joelworsham
路
5Comments
Most helpful comment
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):
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.