«Отказ в соединении» и «Нет маршрута к хосту»


20

У меня сервер Apache работает на сервере:

[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
....

Однако, когда я пытаюсь подключиться к локальному хосту, я получаю «Отказ в соединении»:

[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.

То же самое происходит, когда я пытаюсь подключиться к локальному IP-адресу:

[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.

С другой стороны, когда я пытаюсь сделать то же самое с другого компьютера в той же сети, я получаю другую ошибку «Нет маршрута к хосту»:

[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.

Почему я получаю эти ошибки? И что я должен сделать, чтобы иметь возможность подключиться к серверу http как с того же компьютера, так и с других компьютеров в сети?

ОБНОВЛЕНИЯ: Основываясь на комментариях и ответах, вот еще немного информации:

[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          

Можно ли traceroute 132.70.6.157с обоих серверов сравнить результаты?
— Вернер Хенце

1
443 - это SSL-порты (https). Проверьте свою конфигурацию, чтобы убедиться, что вы слушаете http порт 80.
— Mikpa

Ответы:


13

Покажите вывод netstat -lnp, чтобы мы могли видеть, какие процессы на самом деле прослушивают какие порты на сервере и с какими IP-адресами они связаны.

Что касается второго компьютера, его сетевое подключение выглядит нарушенным. netstat -rnдаст некоторое представление о проблеме там.

Чтобы получить более качественную консультацию, необходимы дополнительные сведения об общей конфигурации сети и конфигурации IP на обоих компьютерах.

Редактировать:

Вы должны изменить конфигурацию Apache, чтобы это был HTTP-сервер, а не SSL-сервер. Файлы конфигурации находятся в / etc / apache2 большую часть времени.

Информация о конфигурации IP и конфигурации сети все еще необходима для анализа другой проблемы. Информация трассировки ничего не раскрыла.


Действительно, нет никакого процесса, слушающего порт 80! Сервер Apache прослушивает порт 443. Но почему это так?
— Эрл Сегал-Халеви

@ErelSegalHalevi: обычно 80 - это HTTP, 443 - это HTTPS (если вы не измените эти порты по умолчанию). Так может приложение ожидает только HTTPS?
— Оливье Дюлак

Благодаря netstat мы узнали, что это действительно проблема конфигурации в Apache.
— Эрель Сегал-Халеви

26

«Отказ в соединении» означает, что целевой компьютер активно отклонил соединение. С портом 80 в качестве контекста одна из следующих вещей, вероятно, является причиной:

  • Ничто не слушает 127.0.0.1:80 и 132.70.6.157:80
  • Ничего не слушает *: 80
  • Брандмауэр блокирует соединение с помощью REJECT.

Так что проверьте ваш конфиг Apache и iptables.

«Нет маршрута к хосту» относится к проблеме сети. Это не ответ от целевой машины.


проблема с сетью? так как же этот домен может вернуть «отказано в соединении» для одного и «нет маршрута к хосту» для другого порта в том же домене?
— phil294

Может быть, ваш брандмауэр или прокси блокирует другой порт, поэтому проблема с сетью?
— croraf

3

Я нашел этот пост, описывающий проблему, с которой я столкнулся при попытке настроить простую страницу http с помощью nodejs на вычислительном узле Public Cloud.

Эта команда сделала свое дело для меня:

iptables -F

Эта команда сбрасывает, т.е. очищает правила брандмауэра, которые установлены внутри системы Linux.

Предостережение: поскольку я использую распределенный брандмауэр, который является частью Public Cloud VCN, я на самом деле не использовал брандмауэр моей ОС. Если у вас нет внешнего брандмауэра, обязательно добавьте правило брандмауэра в iptables.


1

Ссылаясь на ответ Рона Мопина из /networkengineering/33397/debugging-no-route-to-host-over-ethernet :

Сообщение ICMP «нет маршрута к хосту» означает, что ARP не может найти адрес уровня 2 для хоста назначения. Обычно это означает, что хост с таким IP-адресом не подключен или не отвечает.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.