Ich habe gerade ein Upgrade von Mavericks auf Yosemite durchgeführt und curl
kann jetzt keine Loopback-Hostnamen sehen.
Richten Sie zum Testen einen einfachen HTTP-Server ein:
$ python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...
Jetzt kann ich localhost:8000 in Chrome aufrufen. Ich kann es sogar mit wget erreichen. Aber in curl passiert Folgendes:
$ curl localhost:8000
curl: (7) Failed to connect to localhost port 8000: Connection refused
Das hier funktioniert jedoch:
$ curl 127.0.0.1:8000
ich lesediese Antwort zu den Wget-Proxy-Einstellungen, aber es hat nicht geholfen, denn das hier funktioniert:
$ wget --proxy=off localhost:8000
Das ist wirklich frustrierend, da in meiner Datei einige verschiedene Loopback-Hostnamen aufgelistet sind, /etc/hosts
sodass ich Apps lokal entwickeln kann, und ich es gewohnt bin, sie mit Curl zu debuggen.
Ich habe es mit der Curl-Version versucht, die mit OSX geliefert wird:
$ 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
Antwort1
Ich habe es gerade zum Laufen gebracht, 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 damit los ist?
Antwort2
Alternative(erfordert kein sudo oder Ändern /etc/hosts
)- Verwenden Sie immer IPv4, bis Curl intelligenter wird.
$ echo '--ipv4' >> ~/.curlrc
(dann klappt alles wie gewünscht)
Antwort3
Zunächst einmal 0.0.0.0
handelt es sich um eine spezielle Adresse, d. h. „jede beliebige IPv4-Adresse“.
Ein Socket kann entweder an das IPv4- oder das IPv6-Protokoll gebunden werden. Wenn ein Socket an gebunden ist 0.0.0.0
, bedeutet dies, dass er auf alle IPv4-Protokolle hört, die versuchen, eine Verbindung zu ihm herzustellen. Dies wird wie folgt dargestellt:
$ nc -l 0.0.0.0 8085
$ lsof -i4 -Pnl | grep 8085
nc 23994 [xxx] 3u IPv4 [xxx] 0t0 TCP *:8085 (LISTEN)
Das *
Zeichen entspricht dem 0.0.0.0
bei IPv4.
Für IPv6:
$ nc -l :: 8085
$ lsof -i6 -Pnl | grep 8085
nc 24145 [xxx] 3u IPv6 [xxx] 0t0 TCP *:8085 (LISTEN)
Das *
Zeichen entspricht ::
bei IPv6,wie in der offiziellen Spezifikation.
Der Grund dafür ist, dass versucht wird, einen zufälligen Eintrag in curl
aufzulösen , und wie @NickRetallack erwähnt hat, wird dieser Eintrag von ausgewählt, wenn die Auflösung im Standardmodus erfolgt (vermutlich IPv6 oder IPv4, je nachdem, was zuerst aufgelöst wird).localhost
/etc/hosts
curl
localhost
Wenn Sie es im --ipv4
Modus erzwingen, wie von @CharlesHebdough vorgeschlagen, wird Folgendes ausgeführt curl
( localhost
vorausgesetzt 127.0.0.1
, es gibt keine anderen IPv4-Einträge für localhost
in /etc/hosts
).
Jede Implementierung wird localhost
wie gewünscht gelöst. Deshalb hatten Sie mit verschiedenen Tools zeitweise Erfolg.
Um möglichst präzise zu sein, verwenden Sie 127.0.0.1
anstelle von localhost, aber dadurch sind Sie an IPv4 gebunden. localhost
gibt Ihnen die Flexibilität, sowohl mit IPv6- als auch mit IPv4-Protokollen zu arbeiten, allerdings könnten bei einigen Implementierungen Probleme auftreten, wie bei dieser bestimmten Version von curl
.