可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效,请关闭广告屏蔽插件后再试):
问题:
Update: Don't use ".dev". When this was originally posted in 2016, it was fine. Now it's not. Start by changing your TLD to somethinge else like ".localhost" or whatever. (This change would not have fixed my issue, but it might fix yours if you're still using ".dev").
Problem: I've installed Laravel Valet and it all seems to be working except when I ping test.dev
(which just contains an index.htm file and is located in ~/Sites
), after hanging for a long time I get the response ping: cannot resolve test.dev: Unknown host
Here's what I've already done:
- I've gone through the Laravel Valet docs and everything installed fine.
- Apache is not running
/etc/hosts
contains no mention of test.dev
- I'm on valet v1.1.12
- I've restarted my computer
- I've installed php 7.0.7 via homebrew fresh and
--with-fpm
- My
$PATH
contains $PATH:$HOME/.composer/vendor/bin
sudo lsof -n -i:80 | grep LISTEN
returns the caddy
proc
brew services list
returns dnsmasq
and is started
- I've updated brew, run
brew doctor
and all is good there
- I can start and stop valet successfully.
valet paths
returns successfully:
[
"/Users/nateritter/.valet/Sites",
"/Users/nateritter/Sites"
]
- Using
valet link
inside the test
directory has no effect on this issue
Now, in addition to all this, I decided to try all the valet arguments out. valet share
seemed to bork with an error at one point, which is interesting but I'm not sure it has anything to do with the original issue.
ERROR: Tunnel 'command_line' specifies invalid address 'test.dev:80': unexpected '[' in address test.dev:80
After this I get 21 lines of Failed to connect to 127.0.0.1 port 4040: Connection refused
and then an exception:
[Httpful\Exception\ConnectionErrorException]
Unable to connect to "http://127.0.0.1:4040/api/tunnels": 7 Failed to connect to 127.0.0.1 port 4040: Connection refused
fetch-share-url
回答1:
The problem ended up being something to do with dnsmasq
. Using the very thorough this answer to another related SO post, I ended up doing the following to solve my issue:
brew unlink dnsmasq
brew install dnsmasq
brew prune
brew services restart dnsmasq
valet install
Then, just to test before I did a ping, I did dig test.dev
and the response included:
;; ANSWER SECTION:
test.dev. 3599 IN A 127.0.53.53
I'm not sure why the IP is 127.0.53.53 and not 127.0.0.1 but when I did a ping test.dev
it did return ...
PING test.dev (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.036 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.072 ms
Browsing to test.dev worked as well.
One thing to note that I haven't looked into yet is that index.htm
is not recognized by valet/caddy as a potential index file. Not part of the issue, but something interesting to note.
回答2:
I had the same problem, some brew services were stopped, running this command fixed it:
sudo brew services start --all
回答3:
I had everything set up correctly, but had the same issue - could not get the app.dev running.
After running
brew services list
I noticed that all services except dnsmasq were running as "root", but dnsmasq was running on my user.
Stopped dnsmasq with
brew services stop dnsmasq
and started it with:
sudo brew services start dnsmasq
This worked for me, after a few hours of frustration.
回答4:
Nothing mentioned above helped me on macos sierra, but one little remark did:
since I use Google for DNS instead of my ISP. The warning is not to use .dev TLDs for dev environments. Instead, use a suggested TLD like .localhost (which is what I've changed valet to use by way of valet domain localhost. Voila. – Nate Ritter
Avoiding '.dev' and using '.devel' did the trick for me, probably needed if you are on google's 8.8.8.8 dns
回答5:
*.dev
does not work anymore since it is a real TLD. So use something else like *.test
or *.local
.
ping dev.test
PING dev.test (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.051 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.149 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.137 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.133 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.138 ms
64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.166 ms
64 bytes from 127.0.0.1: icmp_seq=6 ttl=64 time=0.142 ms
Also don't forget to add http:// or https:// to your domain like http://blog.test for the first time when you open in the browser. Otherwise it will go to your default search engine.
回答6:
If you're just getting started with Laravel and following the Laracast tutorials, make sure to also read the latest documentation.
In Laravel 5.6 and Valet 2.0.12 the *.dev domains were replaced by *.test, as you can see in here: https://laravel.com/docs/5.6/valet#installation
回答7:
For me somehow a syntax error sneaked into the dnsmasq.conf
which would prevent it from starting up correctly.
To check this I did dnsmasq --test
which gave the following output dnsmasq: bad option at line 1 of /usr/local/etc/dnsmasq.conf
I fixed the typo on line 1 and did restarted all services with brew services restart --all
After that, I can ping again to .dev domains and it works in my browser
ping test.dev
PING test.dev (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.062 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.035 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.056 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.053 ms
--- test.dev ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.035/0.051/0.062/0.010 ms
Hope this will help some one!