web-dev-qa-db-fra.com

Ping test.dev après Laravel L'installation par le valet renvoie "hôte inconnu"

Mise à jour: N'utilisez pas ".dev". Lorsque cela a été publié en 2016, tout allait bien. Maintenant ce n'est pas. Commencez par changer votre TLD en quelque chose d'autre comme ".localhost" ou autre chose. (Cette modification n'aurait pas corrigé mon problème, mais cela pourrait résoudre le vôtre si vous utilisez toujours ".dev").

Problème: J'ai installé Laravel Valet et tout semble fonctionner, sauf quand je ping test.dev (qui ne contient qu'un fichier index.htm et se trouve dans ~/Sites), après avoir été suspendu pendant longtemps je reçois la réponse ping: cannot resolve test.dev: Unknown Host

Voici ce que j'ai déjà fait:

  • J'ai parcouru le Laravel Valet Docs et tout est bien installé.
  • Apache n'est pas en cours d'exécution
  • /etc/hosts ne contient aucune mention de test.dev
  • Je suis sur valet v1.1.12
  • J'ai redémarré mon ordinateur
  • J'ai installé php 7.0.7 via homebrew fresh et --with-fpm
  • Mon $PATH contient $PATH:$HOME/.composer/vendor/bin
  • Sudo lsof -n -i:80 | grep LISTEN retourne le caddy proc
  • brew services list renvoie dnsmasq et est démarré
  • J'ai mis à jour le breuvage, lancez brew doctor et tout va bien ici
  • Je peux démarrer et arrêter le voiturier avec succès.
  • valet paths renvoie avec succès: [ "/Users/nateritter/.valet/Sites", "/Users/nateritter/Sites" ]
  • L'utilisation de valet link dans le répertoire test n'a aucun effet sur ce problème

Maintenant, en plus de tout cela, j'ai décidé d'essayer tous les arguments du valet. valet share semblait avoir une erreur à un moment donné, ce qui est intéressant, mais je ne suis pas sûr que cela ait quelque chose à voir avec le problème original.

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

Après cela, je reçois 21 lignes de Failed to connect to 127.0.0.1 port 4040: Connection refused et ensuite une 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
phplaravellaravel-5laravel-valet
9
Nate Ritter

Le problème a fini par être lié à dnsmasq. En utilisant le très minutieux cette réponse à un autre post connexe SO, j'ai finalement procédé comme suit pour résoudre mon problème:

brew unlink dnsmasq

brew install dnsmasq

brew Prune

brew services restart dnsmasq

valet install

Ensuite, juste pour tester avant de faire un ping, j'ai Dig test.dev et la réponse incluait:

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

Je ne suis pas sûr de savoir pourquoi l'IP est 127.0.53.53 et non 127.0.0.1 mais quand j'ai fait un ping test.dev, il est retourné ...

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

La navigation sur test.dev a également fonctionné.

Une chose à noter que je n'ai pas encore examinée est que index.htm n'est pas reconnu par le valet/cadet comme un fichier d'index potentiel. Ne fait pas partie de la question, mais quelque chose d'intéressant à noter.

18
Nate Ritter

J'ai eu le même problème, certains services de brassage ont été arrêtés, en exécutant cette commande corrige le:

Sudo brew services start --all
18
Agu Dondo

Rien de mentionné ci-dessus m'a aidé sur macos sierra, mais une petite remarque a fait:

depuis que j'utilise Google pour DNS au lieu de mon FAI. L'avertissement est de ne pas utiliser les TLD .dev pour les environnements de développement. Au lieu de cela, utilisez un TLD suggéré, tel que .localhost (c'est ce que j'ai changé de valet pour qu'il soit utilisé par le biais de valet domain localhost. Voilà. - Nate Ritter

Éviter '.dev' et utiliser '.devel' a été efficace, probablement nécessaire si vous êtes sur Google 8.8.8.8 dns

3
woens

J'avais tout configuré correctement, mais j'avais le même problème: impossible de lancer app.dev en cours d'exécution.

Après avoir couru

brew services list

J'ai remarqué que tous les services sauf Dnsmasq s'exécutaient en tant que "root", mais Dnsmasq s'exécutait sur mon utilisateur.

Dnsmasq arrêté avec

brew services stop dnsmasq

et a commencé avec:

Sudo brew services start dnsmasq

Cela a fonctionné pour moi, après quelques heures de frustration.

3
Antonio

Si vous commencez à utiliser Laravel et à suivre les didacticiels Laracast, veillez également à lire la documentation la plus récente.

Dans Laravel 5.6 et Valet 2.0.12, les domaines * .dev ont été remplacés par * .test, comme vous pouvez le voir ici: https://laravel.com/docs/5.6/valet#installation

2
Rafael Mejía

*.dev ne fonctionne plus puisqu'il s'agit d'un véritable TLD. Donc, utilisez quelque chose d'autre comme *.test ou *.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

N'oubliez pas non plus d'ajouter http: // ou https: // à votre domaine, comme http: //blog.test pour la première fois lorsque vous ouvrez le navigateur. Sinon, votre moteur de recherche par défaut sera utilisé.

2
Krishnadas PC

Pour moi, une erreur de syntaxe s'est glissée dans le dnsmasq.conf, ce qui l'empêcherait de démarrer correctement.

Pour vérifier cela, j’ai fait dnsmasq --test qui a donné le résultat suivant dnsmasq: bad option at line 1 of /usr/local/etc/dnsmasq.conf

J'ai corrigé la faute de frappe sur la ligne 1 et redémarré tous les services avec brew services restart --all

Après cela, je peux cingler à nouveau vers des domaines .dev et cela fonctionne dans mon navigateur.

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

J'espère que cela aidera quelqu'un!

0
Maantje