1 votes

Le port 8080 de localhost ne répond pas, mais l'utilisation de 127.0.0.1:8080 fonctionne.

Quand j'essaie d'accéder à locahost:8080, j'obtiens

The localhost page isn’t working

localhost didn’t send any data.
ERR_EMPTY_RESPONSE

mais si j'essaie :

127.0.0.1:8080, j'obtiens la réponse que je recherche

Je pense que cela a quelque chose à voir avec le httpd (apache) que je viens de mettre à jour avec homebrew httpd24(httpd.2.4) ?

J'ai suivi les instructions de mise à jour de ce site : https://getgrav.org/blog/macos-sierra-apache-multiple-php-versions

1 votes

Est-ce que "ping localhost" donne 127.0.0.1 ? Vous pouvez également vérifier /etc/hosts.

0 votes

Oui, ping localhost se résout à 127.0.0.1 127.0.0.1 localhost 255.255.255.255 broadcasthost

0 votes

Avez-vous d'anciens fichiers de configuration qui définissent un hôte virtuel ? Ou y a-t-il quelque chose dans les fichiers journaux d'Apache ? Voyez-vous quelque chose se produire lorsque vous éjectez tous les fichiers journaux et essayez d'accéder à localhost ? "tail -f /usr/local/var/log/apache2/*"

2voto

Jake Points 2460

Après avoir installé httpd24 avec brew vous avez deux environnements de serveur web Apache complètement différents :

  1. httpd24 de brew
  2. le httpd original de macOS/OS X

Les deux ont des fichiers de configuration et des binaires apachectl (et autres) différents. Le premier est installé dans /usr/local/Cellar/httpd24 et ses binaires sont liés à /usr/local/bin. Les binaires liés à httpd de macOS sont situés dans /usr/sbin.

En fonction de votre variable PATH (entrez echo $PATH pour l'obtenir) sudo apachectl [cmd] contrôle soit le premier, soit le second environnement Apache.

Après l'installation de brew, le PATH par défaut devrait être /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin qui favorise le httpd24 de Brew. Vous pouvez cependant contrôler Apache de macOS en utilisant le chemin complet (/usr/sbin/apachectl).

Si vous avez un chemin différent qui ne favorise pas /usr/local/bin par rapport à /usr/sbin, c'est l'inverse. Pour obtenir le chemin de l'option privilégiée apachectl vous pouvez aussi simplement entrer which apachectl .

Vérifiez cela avec /usr/local/bin/apachectl -S ce qui devrait donner :

VirtualHost configuration:
ServerRoot: "/usr/local/opt/httpd24"
Main DocumentRoot: "/usr/local/var/www/htdocs"
Main ErrorLog: "/usr/local/var/log/apache2/error_log"
Mutex default: dir="/usr/local/var/run/apache2/" mechanism=default 
Mutex mpm-accept: using_defaults
PidFile: "/usr/local/var/run/apache2/httpd.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="daemon" id=1 not_used
Group: name="daemon" id=1 not_used

y /usr/sbin/apachectl -S

VirtualHost configuration:
ServerRoot: "/usr"
Main DocumentRoot: "/Library/WebServer/Documents"
Main ErrorLog: "/private/var/log/apache2/error_log"
Mutex default: dir="/private/var/run/" mechanism=default 
Mutex mpm-accept: using_defaults
Mutex proxy-balancer-shm: using_defaults
Mutex proxy: using_defaults
PidFile: "/private/var/run/httpd.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="_www" id=70 not_used
Group: name="_www" id=70 not_used

Hay pas de les fichiers/dossiers utilisés mutuellement.

Ils utilisent également des fichiers de configuration standard différents :

/usr/local/bin/apachectl -t -D DUMP_INCLUDES
Included configuration files:
  (*) /usr/local/etc/apache2/2.4/httpd.conf

La commande ne fonctionne pas correctement pour l'apachectl original (macOS) cependant et ne donne que des résultats : Syntaxe OK.


Si vous exécutez les deux httpds (en configurant des ports différents ici : 80 : macOS ; 8080 httpd24 - vérifiez cela dans les fichiers de configuration respectifs) ps -aef | grep httpd | grep -v grep affichera ce qui suit :

  0    76     1   0  4:54pm ??         0:00.13 /usr/local/opt/httpd24/bin/httpd -D FOREGROUND
  1   219    76   0  4:54pm ??         0:00.00 /usr/local/opt/httpd24/bin/httpd -D FOREGROUND
  1   220    76   0  4:54pm ??         0:00.00 /usr/local/opt/httpd24/bin/httpd -D FOREGROUND
  1   221    76   0  4:54pm ??         0:00.00 /usr/local/opt/httpd24/bin/httpd -D FOREGROUND
  1   222    76   0  4:54pm ??         0:00.00 /usr/local/opt/httpd24/bin/httpd -D FOREGROUND
  1   223    76   0  4:54pm ??         0:00.00 /usr/local/opt/httpd24/bin/httpd -D FOREGROUND
  1  4239    76   0  5:06pm ??         0:00.00 /usr/local/opt/httpd24/bin/httpd -D FOREGROUND
  0  8251     1   0  5:45pm ??         0:00.08 /usr/sbin/httpd -D FOREGROUND
 70  8261  8251   0  5:46pm ??         0:00.00 /usr/sbin/httpd -D FOREGROUND

Les sept premiers pids appartiennent à httpd24, les deux derniers à httpd de macOS - vérifiez les chemins binaires indiqués ! et nmap localhost :

Starting Nmap 7.31 ( https://nmap.org ) at 2016-12-22 18:00 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00039s latency).
Other addresses for localhost (not scanned): ::1 fe80::1
Not shown: 499 closed ports, 498 filtered ports
PORT     STATE SERVICE
80/tcp   open  http
8080/tcp open  http-proxy

Dans votre message de chat privé vous pouvez clairement voir que httpd24 n'est pas ne fonctionne pas du tout, mais le httpd de macOS est .

Pour désactiver le httpd de macOS, exécutez simplement sudo /usr/sbin/apachectl stop et en outre sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist (juste pour être sûr).

Ensuite, jetez le brew service start ... en arrêtant le service et en installant un vrai démon plist comme recommandé dans le guide pratique lié.

sudo cp -v /usr/local/Cellar/httpd24/2.4.23_2/homebrew.mxcl.httpd24.plist /Library/LaunchDaemons
sudo chown -v root:wheel /Library/LaunchDaemons/homebrew.mxcl.httpd24.plist
sudo chmod -v 644 /Library/LaunchDaemons/homebrew.mxcl.httpd24.plist
sudo launchctl load /Library/LaunchDaemons/homebrew.mxcl.httpd24.plist

Redémarrez. Si vous obtenez toujours une erreur en vous connectant avec localhost:8080 à votre site de développement local, commentez les points suivants fe80::1%lo0 localhost dans /etc/hosts. Dans mon environnement, cela fonctionne avec cette ligne cependant.


Après des recherches plus approfondies, il s'avère qu'un proxy web mal configuré (faisant partie de l'Internet Security/Antivirus d'ESET) est le coupable. En ajoutant un localhost exclure il devrait être possible de résoudre le problème.

0 votes

Merci pour votre aide, j'ai essayé vos commandes, aquí est la sortie des commandes dans l'ordre où vous les avez écrites.

0 votes

J'ai utilisé le --privileged-port Je suis également presque prêt à faire une installation propre.

0 votes

Je n'ai pas de dnsmasq en cours d'exécution, bien que j'aie joué avec sa configuration il y a quelque temps. Je n'ai pas effectué de cache mDBSResponder

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X