Laravel Valet 安装后 Ping test.dev 返回“未知主机”

Pinging test.dev after Laravel Valet install returns "Unknown Host"

提问by Nate Ritter

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").

更新：不要使用“.dev”。当这最初是在 2016 年发布时，它很好。现在不是了。首先将您的 TLD 更改为诸如“.localhost”之类的其他内容。（此更改不会解决我的问题，但如果您仍在使用“.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

问题：我已经安装Laravel代客而这一切似乎除了当我是工作ping test.dev（这只是包含一个index.htm文件，位于~/Sites），挂了很长一段时间后，我得到的回应ping: cannot resolve test.dev: Unknown host

Here's what I've already done:

这是我已经做过的事情：

• I've gone through the Laravel Valet docsand everything installed fine.
• Apache is not running
• /etc/hostscontains 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 $PATHcontains $PATH:$HOME/.composer/vendor/bin
• sudo lsof -n -i:80 | grep LISTENreturns the caddyproc
• brew services listreturns dnsmasqand is started
• I've updated brew, run brew doctorand all is good there
• I can start and stop valet successfully.
• valet pathsreturns successfully: [ "/Users/nateritter/.valet/Sites", "/Users/nateritter/Sites" ]
• Using valet linkinside the testdirectory has no effect on this issue

• 我已经浏览了 Laravel Valet 文档，一切都安装得很好。
• Apache 没有运行
• /etc/hosts没有提及 test.dev
• 我在代客 v1.1.12
• 我已经重新启动了我的电脑
• 我已经通过自制软件安装了 php 7.0.7，并且 --with-fpm
• 我的$PATH包含$PATH:$HOME/.composer/vendor/bin
• sudo lsof -n -i:80 | grep LISTEN返回caddyPROC
• brew services list返回dnsmasq并开始
• 我已经更新了 brew，run brew doctor，一切都很好
• 我可以成功启动和停止代客泊车。
• valet paths成功返回： [ "/Users/nateritter/.valet/Sites", "/Users/nateritter/Sites" ]
• valet link在test目录内使用对这个问题没有影响

Now, in addition to all this, I decided to try all the valet arguments out. valet shareseemed 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.

现在，除了所有这些，我决定尝试所有的代客争论。valet share似乎有一次出错，这很有趣，但我不确定它与原始问题有什么关系。

ERROR: Tunnel 'command_line' specifies invalid address 'test.dev:80': unexpected '[' in address test.dev:80

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 refusedand then an exception:

在此之后，我得到 21 行，Failed to connect to 127.0.0.1 port 4040: Connection refused然后是一个例外：

[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

回答by Nate Ritter

The problem ended up being something to do with dnsmasq. Using the very thorough this answerto another related SO post, I ended up doing the following to solve my issue:

问题最终与dnsmasq. 使用对另一篇相关 SO 帖子的非常彻底的回答，我最终执行了以下操作来解决我的问题：

brew unlink dnsmasq

brew unlink dnsmasq

brew install dnsmasq

brew install dnsmasq

brew prune

brew prune

brew services restart dnsmasq

brew services restart dnsmasq

valet install

valet install

Then, just to test before I did a ping, I did dig test.devand the response included:

然后，只是为了在我执行 ping 之前进行测试，我做了dig test.dev并且响应包括：

;; 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.devit did return ...

我不知道为什么 IP 是 127.0.53.53 而不是 127.0.0.1 但是当我做了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.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.

浏览 test.dev 也有效。

One thing to note that I haven't looked into yet is that index.htmis not recognized by valet/caddy as a potential index file. Not part of the issue, but something interesting to note.

我还没有研究过的一件事是，index.htm代客/球童没有将其识别为潜在的索引文件。不是问题的一部分，但需要注意一些有趣的事情。

回答by Agu Dondo

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

我遇到了同样的问题，一些 brew 服务被停止，运行这个命令修复了它：

sudo brew services start --all

回答by Antonio

I had everything set up correctly, but had the same issue - could not get the app.dev running.

我已经正确设置了所有内容，但遇到了同样的问题 - 无法运行 app.dev。

After running

运行后

brew services list

I noticed that all services except dnsmasq were running as "root", but dnsmasq was running on my user.

我注意到除 dnsmasq 之外的所有服务都以“root”身份运行，但 dnsmasq 正在我的用户上运行。

Stopped dnsmasq with

停止 dnsmasq

brew services stop dnsmasq

and started it with:

并开始它：

sudo brew services start dnsmasq

This worked for me, after a few hours of frustration.

经过几个小时的挫折后，这对我有用。

回答by woens

Nothing mentioned above helped me on macos sierra, but one little remark did:

上面提到的任何内容都没有帮助我在 macos sierra 上帮助我，但是有一点意见可以帮助我：

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

因为我使用 Google 作为 DNS 而不是我的 ISP。警告是不要将 .dev TLD 用于开发环境。相反，使用建议的 TLD，如 .localhost（这是我通过代客域 localhost 更改代客使用的。瞧。 – 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

避免使用 '.dev' 并使用 '.devel' 对我有用，如果您使用 google 的 8.8.8.8 dns，可能需要

回答by Krishnadas PC

*.devdoes not work anymore since it is a real TLD. So use something else like *.testor *.local.

*.dev不再工作，因为它是一个真正的 TLD。所以使用其他类似*.test或的东西*.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.testfor the first time when you open in the browser. Otherwise it will go to your default search engine.

当您第一次在浏览器中打开时，也不要忘记将 http:// 或 https:// 添加到您的域中，例如http://blog.test。否则，它将转到您的默认搜索引擎。

回答by Rafael Mejía

If you're just getting started with Laravel and following the Laracast tutorials, make sure to also read the latest documentation.

如果您刚刚开始使用 Laravel 并遵循 Laracast 教程，请务必阅读最新的文档。

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

在 Laravel 5.6 和 Valet 2.0.12 中，*.dev 域被 *.test 替换，正如您在此处看到的：https: //laravel.com/docs/5.6/valet#installation

回答by Maantje

For me somehow a syntax error sneaked into the dnsmasq.confwhich would prevent it from starting up correctly.

对我来说，不知何故，语法错误会潜入dnsmasq.conf其中，这会阻止它正确启动。

To check this I did dnsmasq --testwhich gave the following output dnsmasq: bad option at line 1 of /usr/local/etc/dnsmasq.conf

为了检查这一点，我做dnsmasq --test了以下输出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

我修复了第 1 行的错字，并重新启动了所有服务 brew services restart --all

After that, I can ping again to .dev domains and it works in my browser

之后，我可以再次 ping 到 .dev 域，它可以在我的浏览器中运行

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!

希望这会帮助某人！