Я арендую VPS с установленным Debian под управлением JBoss AS6 для моего веб-приложения. Недавно у меня были проблемы с моими DNS-хостами, поскольку они испортили A-записи для моего домена, что привело к ошибочному добавлению некоторых новых A-записей.
Проблема с DNS теперь отсортирована, и домен работает нормально, однако я заметил, что веб-сервер больше не отвечает через прямой IP-адрес или имя хоста в веб-браузере (хотя он пингует нормально, и я могу использовать SSH в порядке, используя имя хоста).
ОБНОВИТЬ:
Я использую rinetd для перенаправления трафика с 80 на порт 8080, см. Ниже вывод журнала rinetd (IP-адреса замаскированы)
Веб-страница запрошена с использованием www.mydomain.com
16/Jan/2013:11:04:15 92.23.40.45 77.**.6.32 80 77.**.6.32 8080 4923 6196 done-local-closed
Веб-страница запрошена с использованием IP, имени хоста или голого домена (без www)
16/Jan/2013:11:08:21 92.23.40.45 77.**.6.32 80 77.**.6.32 8080 0 0 done-remote-closed
Это наводит на мысль, что запросы принимаются сервером, но журналы rinetd не показывают данных, отправленных / полученных от клиента? Означает ли это, что запрос заблокирован?
ОБНОВЛЕНИЕ СНОВА:
В соответствии с ответом ниже я проверил IP-таблицы для правил брандмауэра, и вывод
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Что, кажется, указывает на отсутствие дополнительных настроек правил?
Я все еще думаю, что это проблема с моим DNS-узлом, поскольку он работал до того, как они подняли A-записи, но они настаивали на правильности сопоставлений, есть ли способ проверить это?
Причина этой проблемы на самом деле была связана с неправильной настройкой сервера приложений (JBoss AS 6), мне нужна была дополнительная запись тега в файле server.xml для голого домена
Если вы можете присоединиться к нему с некоторыми протоколами (ICMP / SSH), но не с HTTP, похоже, что брандмауэр блокирует его (я думаю, вы думали об этом, прежде чем размещать здесь). Еще раз проверьте, нет ли программного или аппаратного брандмауэра! Если вы попробуете проверить порт аппарата, что он вернет? Введите в командной строке клиента следующее: "nc -z 80; echo $?" Если какое-то время сервер не отвечает, хотя работает та же команда с 22 вместо 80, то это подтверждает, что у вас что-то сбрасывает пакеты! Если приведенные выше команды возвращают 1, значит, порт закрыт снаружи. Возможно, веб-сервер больше не прослушивает порт 80. И если вы получите 0, это означает, что порт доступен (тогда все должно быть в порядке).