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

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

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

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

  • Я прошел документы Ларавела Валета и все установлено нормально.
  • 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

9

Решение

Проблема в конечном итоге была связана с dnsmasq, Используя очень тщательный этот ответ к другому связанному 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 не распознает потенциальный индексный файл. Не часть проблемы, но кое-что интересное, чтобы отметить.

18

Другие решения

У меня была такая же проблема, некоторые службы brew были остановлены, с помощью этой команды это удалось исправить:

sudo brew services start --all
18

У меня все настроено правильно, но возникла та же проблема — не удалось запустить app.dev.

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

brew services list

Я заметил, что все сервисы, кроме dnsmasq, работали как «root», но dnsmasq работал на моем пользователе.

Остановил dnsmasq с

brew services stop dnsmasq

и начал это с:

sudo brew services start dnsmasq

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

3

Ничто из упомянутого выше не помогло мне на macos sierra, но одно небольшое замечание сделало:

так как я использую Google для DNS вместо моего провайдера. Предупреждение не должно использовать .dev TLD для сред разработки. Вместо этого используйте предложенный TLD, такой как .localhost (именно это я и изменил для использования valet посредством localhost домена valet. Вуаля. — Нейт Риттер

Избежать «.dev» и использовать «.devel» помогло мне, вероятно, это необходимо, если вы используете Google 8.8.8.8 dns

3

*.dev больше не работает, так как это настоящий ДВУ. Так что используйте что-то еще, как *.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 в первый раз, когда вы открываете в браузере. В противном случае он перейдет к вашей поисковой системе по умолчанию.

2

Если вы только начинаете работать с Laravel и читаете учебные пособия по Laracast, обязательно ознакомьтесь с последней документацией.

В Laravel 5.6 и Valet 2.0.12 домены * .dev были заменены на * .test, как вы можете видеть здесь: https://laravel.com/docs/5.6/valet#installation

2

Для меня каким-то образом синтаксическая ошибка проникла в 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

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

0
По вопросам рекламы [email protected]