"Ligação recusada" vs. "Nenhuma rota para hospedar".

Question

2014-02-24 08:49:11 +0000 2014-02-24 08:49:11 +0000

20

"Ligação recusada" vs. "Nenhuma rota para hospedar".

Tenho um servidor Apache a funcionar num servidor:

[root@te-srv2 ~]# ps -ecf|grep httpd
root 698 32047 TS 19 10:45 pts/24 00:00:00 grep httpd
root 32081 1 TS 19 10:16 ? 00:00:00 /usr/sbin/httpd
apache 32083 32081 TS 19 10:16 ? 00:00:00 /usr/sbin/httpd
apache 32084 32081 TS 19 10:16 ? 00:00:00 /usr/sbin/httpd
....

Contudo, quando tento ligar-me ao anfitrião local recebo “Ligação recusada”:

[root@te-srv2 ~]# wget http://127.0.0.1
--2014-02-24 10:46:16-- http://127.0.0.1/
Connecting to 127.0.0.1:80... failed: Connection refused.

O mesmo acontece quando tento ligar-me ao endereço IP local:

[root@te-srv2 ~]# wget http://132.70.6.157
--2014-02-24 10:46:40-- http://132.70.6.157/
Connecting to 132.70.6.157:80... failed: Connection refused.

Por outro lado, quando tento o mesmo a partir de outro computador na mesma rede, recebo um erro diferente: “No route to host”:

[erelsgl@erel-biu ~]$ wget http://132.70.6.157
--2014-02-24 10:49:11-- http://132.70.6.157/
Connecting to 132.70.6.157:80... failed: No route to host.

Porque estou a receber estes erros? E o que devo fazer para me poder ligar ao servidor http a partir do mesmo computador e de outros computadores na rede?

ACTUALIZAÇÕES: Com base nos comentários e respostas, aqui ficam mais algumas informações:

[root@te-srv2 ~]# traceroute 132.70.6.157
traceroute to 132.70.6.157 (132.70.6.157), 30 hops max, 60 byte packets
 1 te-srv2 (132.70.6.157) 0.082 ms 0.007 ms 0.005 ms

[erelsgl@erel-biu ~]$ traceroute 132.70.6.157
traceroute to 132.70.6.157 (132.70.6.157), 30 hops max, 60 byte packets
 1 te-srv2 (132.70.6.157) 0.446 ms !X 0.431 ms !X 0.420 ms !X

[root@te-srv2 ~]# netstat -lnp|grep http
tcp 0 0 :::443 :::* LISTEN 5756/httpd

Fonte

Erel Segal-Halevi http://superuser.stackexchange.com/users/89652

Respostas (4)

26

2014-02-24 09:11:38 +0000

“Ligação recusada” significa que a máquina alvo rejeitou activamente a ligação. Com a porta 80 como contexto, uma das seguintes coisas é provavelmente a razão:

Nada está a ouvir em 127.0.0.1:80 e 132.70.6.157:80
Nada está a ouvir em *:80
A firewall está a bloquear a ligação com REJECT

Portanto, verifique a configuração do seu Apache e do seu iptables.

“No route to host” refere-se a um problema de rede. É não uma resposta da máquina alvo.

Fonte

Daniel B http://superuser.stackexchange.com/users/89652

3

2018-06-14 09:23:31 +0000

Encontrei este post descrevendo o problema que estava a enfrentar ao tentar configurar uma página http simples usando nodejs num nó de computação Public Cloud.

Este comando fez o truque por mim:

iptables -F

Este comando descarrega, isto é, limpa as regras de firewall que são configuradas dentro do sistema Linux.

Palavra de prudência: Uma vez que utilizo a firewall distribuída que faz parte do VCN da nuvem pública, não utilizei realmente a firewall do meu sistema operativo. No caso de não ter uma firewall externa, certifique-se de adicionar uma regra de firewall em iptables.

Fonte

Sanjeev Gopinath http://superuser.stackexchange.com/users/89652

1

2017-08-01 08:16:53 +0000

Citando a resposta de Ron Maupin de https://networkengineering.stackexchange.com/questions/33397/debugging-no-route-to-host-over-ethernet :

A mensagem do ICMP, “no route to host”, significa que a ARP não consegue encontrar o endereço de camada-2 para o host de destino. Normalmente, isto significa que o anfitrião com esse endereço IP não está online ou a responder.

Fonte

jan http://superuser.stackexchange.com/users/89652

Questões relacionadas

3

O ping transatlântico mais rápido do que enviar um pixel para o ecrã? 818

11

Como verificar que módulos apache estão activados/instalados? 393

13

Teste se uma porta num sistema remoto é alcançável (sem telnet) 369

5

O que significa a "Fi" em "Wi-Fi"? 316

7

Desvantagens da partição de uma SSD? 84

Tero Kilkanen http://superuser.stackexchange.com/users/89652 · Accepted Answer · 2014-02-24 09:09:12 +0000

Mostrar a saída de netstat -lnp, para que possamos ver que processos estão realmente a ouvir que portas no servidor, e a que endereços IP estão ligados.

Em relação ao segundo computador, a sua conectividade de rede parece estar avariada. netstat -rn& dará alguma visão sobre o problema aí.

A fim de dar melhores conselhos, são necessários mais detalhes sobre a configuração geral da rede e a configuração IP em ambos os computadores.

Editar:

Tem de alterar a sua configuração Apache para que seja um servidor HTTP, e não um servidor SSL. Os ficheiros de configuração estão localizados em /etc/apache2 a maior parte do tempo.

A configuração IP e a informação de configuração de rede ainda é necessária para analisar o outro problema. A informação do traceroute não revelou nada.