Нет ответа от сервера linux

Основные ошибки в работе веб-сервера под Linux — диагностика и исправление

Даже если ваш веб-сервер сейчас отлично работает, лучше быть готовым решать типичные проблемы, если они когда-либо произойдут. Ниже мы постарались описать некоторые проблемы и способы их решения. Вот что нужно проверить:

Корректно ли прописаны DNS-записи вашего домена?

Чтобы быть доступным по всему миру, DNS-записи вашего домена должны быть корректно настроены. Чтобы проверить это, просто запустите следующую команду на локальном компьютере. Если в результате вы увидите «внешний» IP вашего сервера, то настройки корректны. В противном случае обратитесь к регистратору домена или в службу поддержки DNS-хостинга.

Работает ли сервер и есть ли на него доступ «извне»?

Зайдите в личный кабинет вашего хостинг-провайдера и убедитесь, что ваш сервер включен и его операционная система работает без сбоев. Обычно хостинг-провайдеры предоставляют прямой доступ к консоли сервера через IPMI или VNC. Подключитесь к консоли сервера «напрямую» и проверьте корректно ли работает операционная система сервера. Если вы видите приглашение для входа в систему как на рисунке ниже, операционная система, вероятнее всего, в порядке, и вы можете проверить доступность сервера по сети.

Для проверки доступности сервера «извне» запустите такую команду на вашем локальном компьютере. Если сервер отвечает на эхо-запросы — все в порядке, если нет — вам следует обратиться в техническую поддержку вашего хостинг-провайдера или самостоятельно устранить сетевые неполадки прежде чем переходить дальше.

Запущены ли на сервере веб-службы?

Следующий шаг — проверка работы веб-сервисов. Чтобы определить, какой именно сервис используется для обеспечения работы сайтов и запущен ли он вообще, вы должны подключиться к серверу через SSH как привилегированный пользователь и дать нижеследующую команду. В норме вы увидите наименование веб-сервиса и его статус в состоянии «выполняется». Если картина иная, то требуется анализ ситуации и исправление возможных проблем.

systemctl list-unit-files | grep -E ‘http|apache|nginx’ # для выяснения, какая именно служба используется как веб-сервер

systemctl enable # для запуска службы после перезагрузки

systemctl start # для запуска сервиса вручную

systemctl status # для проверки статуса службы после запуска

Прослушивается ли веб-порт?

Веб-браузер запрашивает содержимое сайта по сетевому порту 80, это общепринятый стандарт. Данный порт должен прослушиваться и не блокироваться брандмауэром. Для проверки запустите на сервере следующую команду. Вы должны увидеть этот порт 80 и службу, которая его слушает.

Проверка корректности настроек веб-сервера

Чтобы сайт отображался браузером, в конфигурации вашего веб-сервера должен присутствовать раздел, который «относится» к вашему сайту. Минимально необходимые директивы: доменное имя, расположение файлов веб-сайта и «стартовый», его еще называют «индексный» файл.

Также, для «автоматической» проверки корректности конфигурации веб-сервера запустите команду service httpd configtest

Наконец, если все предыдущие проверки пройдены, просто откройте ваш сайт при помощи браузера. Вы должны увидеть стартовую страницу вашего сайта, что будет свидетельствовать об отсутствии проблем.

Источник

Server does not respond to ping — ICMP is received and nothing happens

I have a server with 2 interfaces connected with dhcp to two different subnets. These 2 different subnets are connected to the same switch into 2 different interfaces.

# ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 23: enp10s0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether c4:00:ad:a4:e3:38 brd ff:ff:ff:ff:ff:ff inet 192.168.201.232/24 brd 192.168.201.255 scope global enp10s0 valid_lft forever preferred_lft forever 25: enp11s0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether c4:00:ad:a4:e3:39 brd ff:ff:ff:ff:ff:ff inet 192.168.203.3/24 brd 192.168.203.255 scope global enp11s0 valid_lft forever preferred_lft forever inet6 fe80::c600:adff:fea4:e339/64 scope link valid_lft forever preferred_lft forever 

# ip r default via 192.168.201.1 dev enp10s0 192.168.201.0/24 dev enp10s0 proto kernel scope link src 192.168.201.232 192.168.203.0/24 dev enp11s0 proto kernel scope link src 192.168.203.3 

From my laptop I’m pinging, first to 192.168.201.232 . With tcpdump on that device I see icmp request and response

# tcpdump -s 0 -i any -vvv -nn 'host 192.168.1.30 and not port 22' tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 11:42:05.240967 IP (tos 0x0, ttl 62, id 53809, offset 0, flags [none], proto ICMP (1), length 84) 192.168.1.30 > 192.168.201.232: ICMP echo request, id 55768, seq 1, length 64 11:42:05.240994 IP (tos 0x0, ttl 64, id 42288, offset 0, flags [none], proto ICMP (1), length 84) 192.168.201.232 > 192.168.1.30: ICMP echo reply, id 55768, seq 1, length 64 

# tcpdump -s 0 -i any -vvv -nn 'host 192.168.1.30 and not port 22' tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 11:43:57.037535 IP (tos 0x0, ttl 62, id 19363, offset 0, flags [none], proto ICMP (1), length 84) 192.168.1.30 > 192.168.203.3: ICMP echo request, id 55808, seq 1, length 64 11:43:58.060756 IP (tos 0x0, ttl 62, id 19364, offset 0, flags [none], proto ICMP (1), length 84) 192.168.1.30 > 192.168.203.3: ICMP echo request, id 55808, seq 2, length 64 

What happens with this packet?
Why there’s no icmp response?
I would expect the icmp response to go to the default gw ( 192.168.201.1 ) because my ip is 192.168.1.30 There’s nothing in iptables and statistics doesn’t increase with netstat -s . When I remove dhcp and interface enp10s0 doesn’t get ip, so I have one route

# ip r default via 192.168.203.1 dev enp11s0 192.168.203.0/24 dev enp11s0 proto kernel scope link src 192.168.203.3 

Источник

Нет ответа от сервера c nginx на некоторые syn?

Есть сервер с Debian Squeeze, на нём установлен nginx 0.7.67 (из репозитория).

В принципе, всё работает без проблем, но заметили, что иногда не получается приконнектиться к порту. SYN приходит, ответа нет.

Пробовал включить syncookies, это несколько помогло (в логах вылезли ошибки про «possible SYN flooding on port 80. Sending cookies.»). Но всё равно были проблемы с коннектом. Синфлуда при этом нет, это просто много легального трафика.

После этого, увеличил следующие параметры:

net.core.somaxconn = 128000 
net.core.netdev_max_backlog = 10000 
net.ipv4.tcp_max_syn_backlog = 128000

У нжинкса увеличил listen backlog до 65536.

Сообщения про «possible SYN flooding» исчезли, однако всё равно периодически не приконнектится к серверу. Проверял простеньким скриптом, который поднимает 20 тредов и открывает и закрывает сокеты к 80-му порту в каждом треде.

Из 1000 попыток открыть сокет около 30-50 отваливаются по таймауту (2 секунды), остальные при этом коннектятся практически мгновенно.

При всём этом в dmesg пусто, в error.log нжинкса тоже пусто.

user www-data; 
worker_processes 2; 
worker_rlimit_nofile 65535; 
error_log /var/log/nginx/error.log; 
pid /var/run/nginx.pid; 
 
events worker_connections 65535; 
use epoll; 
> 
server listen 80 default backlog=65536; 
. 
>

На сервере 2 ядра, LoadAverage держится меньше единицы.

В netstat’e примерно такая картина:

# netstat -ant | grep tcp | tr -s ' ' ' ' | awk '' | sort | uniq -c 
22 CLOSING 
3729 ESTABLISHED 
815 FIN_WAIT1 
3807 FIN_WAIT2 
138 LAST_ACK 
5 LISTEN 
167 SYN_RECV 
37 SYN_SENT 
1104 TIME_WAIT

Active connections: 5985 
server accepts handled requests 
35200 35200 34437 
Reading: 341 Writing: 223 Waiting: 5421

На всякий случай — SYNы до сервера точно доходят, снимал tcpdump, в нём они видны.

Подскажите, пожалуйста, что смотреть, куда копать, кто сталкивался?

Источник