Locken Sie lokale Hostnamen unter Mac OS X Yosemite

Ich habe gerade ein Upgrade von Mavericks auf Yosemite durchgeführt und curlkann jetzt keine Loopback-Hostnamen mehr sehen.

Richten Sie einen einfachen HTTP-Server zum Testen ein:

$ python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...

Jetzt kann ich localhost treffen: 8000 in Chrom. Ich kann es sogar wget. Aber im Curl passiert Folgendes:

$ curl localhost:8000
curl: (7) Failed to connect to localhost port 8000: Connection refused

Dies funktioniert jedoch:

$ curl 127.0.0.1:8000

Ich habe diese Antwort über die wget-Proxy-Einstellungen gelesen , aber es hat nicht geholfen, da dies funktioniert:

$ wget --proxy=off localhost:8000

Dies ist sehr frustrierend, da in meiner /etc/hostsDatei einige verschiedene Loopback-Hostnamen aufgeführt sind, damit ich Apps lokal entwickeln kann, und ich bin es gewohnt, sie mit Curl zu debuggen.

Ich habe es mit der mit osx gelieferten Version von curl versucht:

$ curl --version
curl 7.37.1 (x86_64-apple-darwin14.0) libcurl/7.37.1 SecureTransport zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IPv6 Largefile NTLM NTLM_WB SSL libz

$ curl localhost:8000
curl: (7) Failed to connect to localhost port 8000: Connection refused

$ curl 127.0.0.1 # works

Und ich habe versucht, Curl mit Brew zu kompilieren:

$ /usr/local/Cellar/curl/7.38.0/bin/curl --version
curl 7.38.0 (x86_64-apple-darwin14.0.0) libcurl/7.38.0 SecureTransport zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: IPv6 Largefile NTLM NTLM_WB SSL libz

$ /usr/local/Cellar/curl/7.38.0/bin/curl localhost:8000
curl: (7) Failed to connect to localhost port 8000: Connection refused

$ /usr/local/Cellar/curl/7.38.0/bin/curl 127.0.0.1:8000 # works

Ich habe es gerade erst geschafft, indem ich eine der IPv6-Loopback-Zeilen aus meiner Datei / etc / hosts auskommentiert habe:

#fe80::1%lo0    localhost

Jetzt funktionieren alle meine Loopback-Hostnamen, nicht nur localhost. Ich frage mich, was ist damit los?

Alternative (erfordert kein Sudo oder Modifizieren /etc/hosts) - Verwenden Sie immer ipv4, bis die Wellung schlauer wird.

$ echo '--ipv4' >> ~/.curlrc

(dann funktioniert alles wie gewünscht)

Zuallererst 0.0.0.0ist eine spezielle Adresse, die "eine beliebige IPv4-Adresse" bedeutet.

Ein Socket kann entweder an ein IPv4- oder ein IPv6-Protokoll gebunden werden. Wenn ein Socket an gebunden 0.0.0.0ist, bedeutet dies, dass er alle IPv4-Verbindungen überwacht und wie folgt dargestellt wird:

$ nc -l 0.0.0.0 8085
$ lsof -i4 -Pnl | grep 8085
  nc        23994 [xxx]    3u  IPv4 [xxx]      0t0  TCP *:8085 (LISTEN)

Das *Vorzeichen entspricht 0.0.0.0IPv4.

Für IPv6:

$ nc -l :: 8085
$ lsof -i6 -Pnl | grep 8085
  nc        24145 [xxx]    3u  IPv6 [xxx]      0t0  TCP *:8085 (LISTEN)

Das *Vorzeichen entspricht ::IPv6 wie in der offiziellen Spezifikation .

Der Grund dafür ist, dass curlversucht wird, einen zufälligen localhostEintrag in /etc/hostsaufzulösen. Wie @NickRetallack bereits erwähnt, wird dieser Eintrag curlbeim Auflösen localhostim Standardmodus ausgewählt (vermutlich IPv6 oder IPv4, was auch immer zuerst aufgelöst wird).

Das Erzwingen des --ipv4Modus, wie von @CharlesHebdough vorgeschlagen, löst das curlProblem localhostauf 127.0.0.1(vorausgesetzt, es gibt keine anderen IPv4-Einträge für localhostin /etc/hosts).

Jede Implementierung wird localhostnach Belieben ausgeführt, weshalb Sie zeitweise mit unterschiedlichen Tools erfolgreich waren.

Um möglichst genau zu sein, verwenden Sie 127.0.0.1anstelle von localhost, aber es wird Sie an IPv4 binden. localhostbietet Ihnen die Flexibilität, sowohl mit IPv6- als auch mit IPv4-Protokollen zu arbeiten. In einigen Implementierungen kann es jedoch zu Problemen kommen, z. B. in dieser bestimmten Version von curl.