Pinging test.dev after Laravel Valet install returns “Unknown Host”

Question

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

Answer 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.

Answer 2

I had the same problem, some brew services were stopped, running this command fixed it:

sudo brew services start --all

Answer 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.

Answer 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

Answer 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.

Answer 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

Answer 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!