cURL не може да се свърже с localhost, но браузърът може

Изпълнявам приложение на Rails локално (тънък сървър) и мога да се свържа локално от браузъра (localhost:3000), но когато се опитам да използвам curl, получавам:

curl -H 'id:1' -i 'http://localhost:3000/api/data' -v

* Hostname was NOT found in DNS cache
*   Trying ::1...
* Adding handle: conn: 0x7fd121808200
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fd121808200) send_pipe: 1, recv_pipe: 0
* Connection failed
* connect to ::1 port 3000 failed: Connection refused
*   Trying fe80::1...
* Connection failed
* connect to fe80::1 port 3000 failed: Connection refused
* Failed to connect to localhost port 3000: Connection refused
* Closing connection 0
curl: (7) Failed to connect to localhost port 3000: Connection refused

Преди това работеше добре, но наскоро актуализирах до Mavericks, което подозирам, че може да е счупило нещо. Мога да се къдря успешно и от мрежата.


ruby-on-rails curl thin osx-mavericks
person jbeck    schedule 07.01.2014    source източник
comment
можеш ли да опиташ http://127.0.0.1:3000/api/data? Изглежда, че по някаква причина curl отива направо към ipv6...   -  person fvu    schedule 08.01.2014
comment
Благодаря, изглежда, че работи. Някаква идея защо това изведнъж се е случило?   -  person jbeck    schedule 08.01.2014
comment
Аз не съм mac-person, но мисля, че записът за localhost може да е изчезнал от /etc/hosts (трябва да има ред като 127.0.0.1 localhost, за да свърже името localhost с обратния адрес 127.0.0.1. Ако този ред е там , може да има проблем с resolv.conf или какъвто и да е файл за конфигурация, който mac използва, за да реши дали да се консултира с hostsfile и/или dns и реда, в който го прави.   -  person fvu    schedule 08.01.2014
comment
Погледнете тук apple.stackexchange.com/questions/107840/, изглежда, че стартирането на dscacheutil -flushcache може да е това, което трябва да направите (приемайки, че /etc/ домакините са добре)   -  person fvu    schedule 08.01.2014

Отговори (6)


arrow_upward
55
arrow_downward

Това е бъг при curl (странно), където curl не успява да се върне към IPv4, ако има IPv6 запис в /etc/hosts, който не не отговарям.

Можете да го принудите да използва IPv4 чрез опцията -4.

person Steve Clay    schedule 24.03.2014
comment
Добавете -4 към вашата команда: curl -4 -H 'id:1' -i 'localhost:3000/api /данни' -v - person Kylar; 12.11.2014
comment
Изглежда, че е проблем с IPv6. Ако коментирам fe80::1%lo0 localhost от моя файл /etc/hosts, curl работи добре. Имам два mac, и двата Yosemite, но само един от тях има този запис. Може ли някой да коментира защо един хост ще има IPv6 запис за localhost? - person George Armhold; 18.02.2015
comment
Друг доклад за IPv6 loopback, причиняващ проблем: superuser.com/a/831695/11889. - person George Armhold; 18.02.2015
comment
Благодаря, Стив, +1 за връзката към доклада за грешка - person David; 19.06.2015
comment
Възможно ли е да го зададете чрез curl_setopt в php? - person Gino Pane; 07.11.2016
comment
по дяволите, загубих няколко часа за това...много благодаря за намека - person pkaramol; 27.03.2019

arrow_upward
22
arrow_downward

Вместо

curl localhost:3000

опитвам

curl 0.0.0.0:3000

Работи.
Ако не работи, проверете изхода, когато стартирате вашия rails сървър:

=> Booting WEBrick
=> Rails 3.2.13 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2014-10-28 15:30:08] INFO  WEBrick 1.3.1
[2014-10-28 15:30:08] INFO  ruby 2.0.0 (2014-02-24) [x86_64-darwin12.5.0]
[2014-10-28 15:30:08] INFO  WEBrick::HTTPServer#start: pid=4004 port=3000

Използвайте URL адреса в края на ред 2 вместо ENV['HOST']

person Marco Prins    schedule 28.10.2014
comment
Защо работи с 0.0.0.0:3000, а не с localhost:3000? - person allegutta; 19.01.2015

arrow_upward
5
arrow_downward

Зад прокси ли сте? След това използвайте по-долу, за да заобиколите напълно проксито.

curl -x "" "http://127.0.0.1:3000"
person Pithikos    schedule 21.01.2016

arrow_upward
1
arrow_downward

Ако приемем, че не сте пипали /etc/hosts и scutil отчетите са положителни:

$ scutil -r 127.0.0.1
Reachable,Local Address
$ scutil -r localhost
Reachable,Local Address

тогава моето предположение е, че защитната стена е активна и не приема връзки от curl.

Опитайте да добавите curl към списъка с приети приложения под (Предполагам за езиковите алтернативи, тъй като машината ми е настроена да използва шведски) Предпочитания --> Сигурност --> Алтернативи на защитната стена --> знак плюс --> (потърсете curl и добавете го)

Забележка: уверете се, че сте добавили къдрицата, която всъщност използвате във вашата черупка.

$ type -a curl
curl is /opt/local/bin/curl
curl is /usr/bin/curl
person FredrikHedman    schedule 22.03.2014

arrow_upward
0
arrow_downward

Друга причина за този проблем може да бъде лошо конфигурирана система с прокси адрес. Бягай

export http_proxy=

и изпълнете отново командата curl, за да елиминирате това като допринасящ фактор. Това реши този проблем за мен.

person Philluminati    schedule 30.09.2015

arrow_upward
0
arrow_downward

Рестартирането на компютъра понякога може да коригира странни проблеми с връзката. Не съм сигурен защо.

person Bryan Aneux    schedule 22.02.2021