Pinging test.dev после установки Laravel Valet возвращает «Неизвестный хост»

Question

Обновление: Не используйте «.dev». Когда это было первоначально опубликовано в 2016 году, все было в порядке. Теперь это не так. Начните с изменения вашего TLD на что-то еще, например «.localhost» или что-то еще. (Это изменение не устранило бы мою проблему, но это может исправить, если вы все еще используете «.dev»).

Проблема: Я установил Laravel Valet, и все это, кажется, работает, за исключением, когда я ping test.dev (который содержит только файл index.htm и находится в ~/Sites), после того, как висит в течение длительного времени я получаю ответ ping: cannot resolve test.dev: Unknown host

Вот что я уже сделал:

• Я прошел через the Laravel Valet docs и все установлено отлично.
• 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 возвращает caddy прок
• brew services list возвращается dnsmasq и запускается
• Я обновил варево, запустить brew doctor и все хорошо там
• я могу начать и успешно остановить камердинера.
• valet paths возвращается успешно: [ "/Users/nateritter/.valet/Sites", "/Users/nateritter/Sites" ]
• Использование valet link внутри каталога test не оказывает никакого влияния на этот вопрос

Теперь, в дополнение ко всему этому, я решил попробовать все аргументы камердинера вне. valet share, похоже, с ошибкой в ​​какой-то момент, что интересно, но я не уверен, что это имеет какое-то отношение к исходной проблеме.

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

После этого я получаю 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 

Answer 1

Проблема закончилась тем, что было что-то делать с dnsmasq.Использование очень тщательно this answer к другому, связанные с SO пост, я в конечном итоге делает следующее, чтобы решить мою проблему:

brew unlink dnsmasq

brew install dnsmasq

brew prune

brew services restart dnsmasq

valet install

Затем, чтобы проверить, прежде чем я сделал пинг, я сделал dig test.dev и ответ включали:

;; ANSWER SECTION: 
test.dev.  3599 IN A 127.0.53.53 

Я не знаю, почему 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 

Просматривая test.dev, также работал.

Одно замечание, которое я еще не изучил, заключается в том, что index.htm не признан valet/caddy в качестве файла индекса потенциала. Не часть проблемы, но что-то интересное.

Answer 2

У меня была такая же проблема, некоторые варят услуги были остановлены, работает эта команда зафиксировал его:

sudo brew services start --all 

Answer 3

я все настроено правильно, но была такая же проблема - не может получить app.dev ход ,

После запуска

brew services list 

Я заметил, что все услуги, кроме Dnsmasq были запущены как «корень», но Dnsmasq был запущен на моем пользователя.

Остановился Dnsmasq с

brew services stop dnsmasq 

и начал его:

sudo brew services start dnsmasq 

Это работает для меня, после нескольких часов разочарования.

Answer 4

Ничто упоминалось выше, не помогло мне на MacOS Сиерра, но одно маленькое замечание сделал:

, поскольку я использую Google для DNS вместо моего провайдера. Предупреждение не должно использоваться .dev TLD для среды разработки. Вместо этого следует использовать предложенный TLD как .localhost (что я изменил камердинер использовать в качестве домена камердинера локального хоста вуаля -.. Nate Ritter

избежать «.dev» и использование».devel "сделал трюк для меня, вероятно, является необходимым, если вы на Google в 8.8.8.8 днсе

Answer 5

Для меня как-то ошибки синтаксиса прокралась в dnsmasq.conf, который не допускал бы его от запуска правильно.

Чтобы проверить это я dnsmasq --test который дал следующий результат dnsmasq: bad option at line 1 of /usr/local/etc/dnsmasq.conf

Я зафиксировал опечатку в строке 1 и не перезапускается все услуги с brew services restart --all

После этого, я могу пинговать снова в .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 

Надеюсь, это поможет кому-то!

Answer 6

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

Также не забудьте добавить HTTP: // или https: // ваш домен, как http://blog.test впервые при открытии в браузере. В противном случае он перейдет к поисковой системе по умолчанию.