Как устранять распространенные проблемы с сайтом на сервере Linux

Введение

У всех рано или поздно возникают проблемы с веб-сервером или сайтом. Знание того, где искать, когда вы сталкиваетесь с проблемой, и какие компоненты являются вероятными виновниками, поможет вам решить эти проблемы как можно быстрее и надежнее.

В этом руководстве вы узнаете, как устранять эти проблемы, чтобы вы могли снова запустить свой сайт.

Какие типы проблем являются типичными?

Большинство проблем, с которыми вы столкнетесь при попытке запустить свой сайт, попадают в предсказуемый спектр.

Мы рассмотрим их более подробно в следующих разделах, а пока вот контрольный список пунктов, на которые стоит обратить внимание:

Установлен ли ваш веб-сервер?
Работает ли веб-сервер?
Правилен ли синтаксис файлов конфигурации вашего веб-сервера?
Открыты ли настроенные вами порты (не заблокированы ли они брандмауэром)?
Ваши настройки DNS направляют вас в нужное место?
Указывает ли корень документа на расположение ваших файлов?
Отправляет ли ваш веб-сервер правильные индексные файлы?
Правильно ли указаны разрешения и права собственности на структуры файлов и каталогов?
Ограничиваете ли вы доступ через файлы конфигурации?
Если у вас есть серверная часть базы данных, работает ли она?
Может ли ваш сайт успешно подключиться к базе данных?

Это некоторые из распространенных проблем, с которыми сталкиваются администраторы, когда сайт работает неправильно. Точную проблему обычно можно сузить, просмотрев файлы журналов различных компонентов и обратившись к страницам ошибок, отображаемым в вашем браузере.

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

Проверьте журналы

Прежде чем слепо пытаться отследить проблему, попробуйте проверить журналы вашего веб-сервера и любых связанных с ним компонентов. Обычно они находятся в /var/log в подкаталоге, специфичном для службы.

Например, если у вас есть сервер Apache, работающий на сервере Ubuntu, по умолчанию журналы будут храниться в /var/log/apache2. Проверьте файлы в этом каталоге, чтобы узнать, какие сообщения об ошибках генерируются. Если у вас есть серверная часть базы данных, которая доставляет вам проблемы, она, вероятно, также будет хранить свои журналы в /var/log.

Также нужно проверить, оставляют ли сами процессы сообщения об ошибках при запуске служб. Если вы попытаетесь посетить веб-страницу и получите сообщение об ошибке, страница с ошибкой также может содержать подсказки (хотя и не такие конкретные, как строки в файлах журнала).

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

Установлен ли ваш веб-сервер?

Первое, что вам, вероятно, понадобится для правильного обслуживания ваших сайтов, — это веб-сервер. В некоторых случаях ваши веб-страницы могут обслуживаться непосредственно контейнером Docker или каким-либо другим приложением, и на самом деле вам не нужно устанавливать выделенный веб-сервер, но в большинстве развертываний по-прежнему будет как минимум один.

Большинство людей установили сервер до того, как дошли до этого момента, но бывают ситуации, когда вы могли случайно удалить сервер при выполнении других операций с пакетами.

Если вы работаете в системе Ubuntu или Debian и вам необходимо установить веб-сервер Apache, вы можете ввести:

sudo apt-get update
sudo apt-get install apache2

В этих системах процесс Apache называется apache2.

Если вы используете Ubuntu или Debian и хотите использовать веб-сервер Nginx, вместо этого вы можете ввести:

sudo apt-get update
sudo apt-get install nginx

В этих системах процесс Nginx называется nginx.

Если вы используете RHEL, Rocky Linux или Fedora и вам нужно использовать веб-сервер Apache, вы можете ввести:

sudo dnf install httpd

В этих системах процесс Apache называется httpd.

Если вы используете RHEL, Rocky Linux или Fedora и хотите использовать Nginx, вы можете ввести это. Опять же, удалите «sudo», если вы вошли в систему как root:

sudo dnf install nginx

В этих системах процесс Nginx называется nginx. В отличие от Ubuntu, Nginx не запускается автоматически после установки в этих дистрибутивах на основе RPM. Читайте дальше, чтобы узнать, как его запустить.

Ваш веб-сервер работает?

Теперь, когда вы уверены, что ваш сервер установлен, он работает?

Существует множество способов узнать, запущена служба или нет. Один из методов, который является довольно кросс-платформенным, заключается в использовании команды netstat.

Запуск netstat с флагами -plunt покажет вам все процессы, использующие порты на сервере. Чтобы узнать больше о запуске netstat, вы можете обратиться к статье Как использовать Top, Netstat, Du и другие инструменты для мониторинга ресурсов сервера. Затем вы можете grep вывести netstat имя процесса, который вы ищете:

sudo netstat -plunt | grep nginx

Outputtcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      15686/nginx: master
tcp6       0      0 :::80                   :::*                    LISTEN      15686/nginx: master

Вы можете изменить nginx на имя процесса веб-сервера на вашем сервере. Если вы видите строку, подобную приведенной выше, это означает, что ваш процесс запущен и работает. Если вы не получили никаких результатов, это означает, что вы запросили неправильный процесс или ваш веб-сервер не работает.

Если ваш веб-сервер не запущен, вы можете запустить его с помощью системы инициализации вашего дистрибутива Linux. Большинство программ, предназначенных для работы в фоновом режиме, после установки регистрируются в системе инициализации, чтобы вы могли запускать и останавливать их программно. В большинстве дистрибутивов теперь используется одна и та же система инициализации, systemd, которая предоставляет команду systemctl.

Например, вы можете запустить службу nginx, набрав:

sudo systemctl start nginx

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

Правилен ли синтаксис вашего файла конфигурации веб-сервера?

Если ваш веб-сервер не удалось запустить, это обычно указывает на то, что ваши файлы конфигурации требуют некоторого внимания. И Apache, и Nginx требуют строгого соблюдения своего синтаксиса, чтобы их конфигурация была правильно проанализирована.

Файлы конфигурации для системных служб обычно находятся в подкаталоге каталога /etc/, названного в честь самого процесса.

Например, вы можете попасть в основной каталог конфигурации Apache в Ubuntu, набрав:

cd /etc/apache2

Каталог конфигурации Apache в RHEL, Rocky и Fedora также отражает имя RHEL для этого процесса:

cd /etc/httpd

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

Каждый из этих веб-серверов также предоставляет способ проверки синтаксиса конфигурации ваших файлов.

Если вы используете Apache, вы можете использовать команду apache2ctl или apachectl, чтобы проверить файлы конфигурации на наличие синтаксических ошибок:

apache2ctl configtest

OutputAH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message
Syntax OK

Синтаксис в порядке по сути означает, что нет серьезных ошибок, препятствующих работе сервера, и каждое сообщение, напечатанное до этого, является незначительной ошибкой или предупреждением. В этом случае Не удалось надежно определить полное доменное имя сервера отражает стандартную настройку Apache на сервере, для которого еще не было настроено доменное имя, но который должен быть доступным по его IP-адресу.

Если у вас есть веб-сервер Nginx, вы можете запустить аналогичный тест, набрав:

sudo nginx -t

Outputnginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Если вы удалите точку с запятой в конце строки конфигурации в /etc/nginx/nginx.conf (распространенная ошибка для конфигураций Nginx), вы получите следующее сообщение:

sudo nginx -t

Outputnginx: [emerg] invalid number of arguments in "tcp_nopush" directive in /etc/nginx/nginx.conf:18
nginx: configuration file /etc/nginx/nginx.conf test failed

Недопустимое количество аргументов, так как Nginx ищет точку с запятой для завершения операторов. Если он не находит его, он переходит к следующей строке и интерпретирует ее как дополнительные аргументы для последней строки.

Вы можете запустить эти тесты, чтобы найти синтаксические проблемы в ваших файлах. Исправьте проблемы, на которые он ссылается, пока вы не сможете получить файлы для прохождения теста.

Настроенные вами порты открыты?

Как правило, веб-серверы используют порт 80 для веб-трафика HTTP и используют порт 443 для трафика HTTPS, зашифрованного с помощью TLS/SSL. Чтобы пользователи могли попасть на ваш сайт, эти порты должны быть доступны.

Вы можете проверить, открыт ли порт вашего сервера, запустив netcat с вашего локального компьютера.

Вам нужно будет использовать IP-адрес вашего удаленного сервера и указать ему, какой порт проверять, например:

nc -z 111.111.111.111 80

Это проверит, открыт ли порт 80 на сервере 111.111.111.111. Если он открыт, команда вернется сразу. Если он не открыт, команда будет постоянно безуспешно пытаться установить соединение. Вы можете остановить этот процесс, нажав CTRL+C в окне терминала.

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

Ваши настройки DNS направляют вас в нужное место?

Если вы можете получить доступ к своему сайту по его IP-адресу, но не через настроенное вами доменное имя, вам может потребоваться взглянуть на настройки DNS.

Чтобы посетители могли попасть на ваш сайт через его доменное имя, у вас должна быть запись \A или \AAAA, указывающая на IP-адрес вашего сервера в настройках DNS. Вы можете запросить запись \A вашего домена с помощью команды host на локальном компьютере или:

host -t A example.com

Output
example.com has address 93.184.216.119

Возвращаемая вам строка должна совпадать с IP-адресом вашего сервера. Если вам нужно проверить запись «AAAA» (для соединений IPv6), вы можете ввести:

host -t AAAA example.com

Output
example.com has IPv6 address 2606:2800:220:6d:26bf:1447:1097:aa7

Имейте в виду, что любые изменения, которые вы вносите в свои записи DNS, могут занять некоторое время для распространения, в зависимости от вашего регистратора доменных имен. Иногда может быть полезно использовать такой сайт, как https://www.whatsmydns.net/, чтобы проверить, когда ваши изменения DNS вступили в силу во всем мире (обычно через полчаса или около того). Вы можете получить противоречивые результаты для этих запросов после внесения изменений, так как ваш запрос часто будет попадать на разные серверы, которые еще не обновлены.

Если вы используете DigitalOcean, вы можете узнать, как настроить параметры DNS для своего домена, здесь.

Убедитесь, что ваши файлы конфигурации также правильно обрабатывают ваш домен

Если ваши настройки DNS верны, вы также можете проверить файлы виртуального хоста Apache или файлы блоков сервера Nginx, чтобы убедиться, что они настроены для ответа на запросы для вашего домена.

В Apache файл вашего виртуального хоста может выглядеть так:

&lt;VirtualHost *:80&gt;
    ServerName example.com
    ServerAlias www.example.com
    ServerAdmin admin@example.com
    DocumentRoot /var/www/html
. . .

Этот виртуальный хост настроен так, чтобы отвечать на любые запросы через порт 80 для домена example.com.

Аналогичный фрагмент в Nginx может выглядеть примерно так:

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    root /usr/share/nginx/html;
    index index.html index.htm;
    server_name example.com www.example.com;
. . .

Эти два блока настроены для ответа на одни и те же типы запросов по умолчанию.

Указывает ли корень документа на расположение ваших файлов?

Еще одно соображение заключается в том, указывает ли ваш веб-сервер на правильное расположение файла.

Каждый виртуальный сервер в Apache или серверный блок в Nginx настроен так, чтобы указывать на определенный порт или локальный каталог. Если это настроено неправильно, сервер выдаст сообщение об ошибке при попытке доступа к странице.

В Apache корневой каталог документа настраивается с помощью директивы DocumentRoot:

&lt;VirtualHost *:80&gt;
    ServerName example.com
    ServerAlias www.example.com
    ServerAdmin admin@example.com
    DocumentRoot /var/www/html
. . .

Эта строка сообщает Apache, что он должен искать файлы для этого домена в каталоге /var/www/html. Если ваши файлы хранятся в другом месте, вам придется изменить эту строку, чтобы указать правильное место.

В Nginx директива root настраивает то же самое:

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    root /usr/share/nginx/html;
    index index.html index.htm;
    server_name example.com www.example.com;
. . .

В этой конфигурации Nginx ищет файлы для этого домена в каталоге /usr/share/nginx/html.

Ваш веб-сервер обслуживает правильные индексные файлы?

Если ваш корень документа правильный и ваши страницы индекса не обслуживаются правильно, когда вы переходите на свой сайт или в каталог на вашем сайте, возможно, ваши индексы настроены неправильно.

В зависимости от сложности ваших веб-приложений многие веб-серверы по-прежнему будут по умолчанию обслуживать индексные файлы. Обычно это файл index.html или файл index.php в зависимости от вашей конфигурации.

В Apache вы можете найти строку в файле вашего виртуального хоста, которая явно настраивает порядок индексации, который будет использоваться для определенных каталогов, например:

&lt;Directory /var/www/html&gt;
    DirectoryIndex index.html index.php
&lt;/Directory&gt;

Это означает, что при обслуживании каталога Apache сначала будет искать файл с именем index.html и попытается использовать index.php в качестве резервной копии, если первый файл не найден.

Вы можете установить порядок, который будет использоваться для обслуживания индексных файлов для всего сервера, отредактировав файл mods-enabled/dir.conf, в котором будут установлены значения по умолчанию для сервера. Если ваш сервер не обслуживает индексный файл, убедитесь, что в вашем каталоге есть индексный файл, соответствующий одному из параметров в вашем файле.

В Nginx директива, которая делает это, называется index и используется следующим образом:

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    root /usr/share/nginx/html;
    index index.html index.htm;
    server_name example.com www.example.com;
. . .

Правильно ли установлены разрешения и права собственности?

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

Для чтения файлов каталоги, содержащие содержимое, должны быть доступны для чтения и выполнения учетной записью пользователя, связанной с веб-сервером. В Ubuntu и Debian Apache и Nginx запускаются от имени пользователя www-data, который является членом группы www-data.

В RHEL, Rocky и Fedora Apache работает под пользователем apache, который принадлежит к группе apache. Nginx работает под пользователем nginx, который является частью группы nginx.

Имея это в виду, вы можете посмотреть файлы и папки, которые вы размещаете:

ls -l /path/to/web/root

Каталоги должны быть доступны для чтения и выполнения веб-пользователем или группой, а файлы должны быть доступны для чтения для чтения содержимого. Чтобы загружать, записывать или изменять контент, каталоги должны быть доступны для записи, а файлы также должны быть доступны для записи.

Чтобы изменить владельца файла, вы можете использовать chown:

sudo chown user_owner:group_owner /path/to/file

Это также можно сделать с каталогом. Вы можете изменить владельца каталога и всех файлов в нем, передав флаг -R:

sudo chown -R user_owner:group_owner /path/to/file

Чтобы узнать больше о разрешениях, обратитесь к Введение в разрешения Linux.

Ограничиваете ли вы доступ через свои файлы конфигурации?

Настройки вашего веб-сервера также могут быть настроены на отказ в доступе к файлам, которые вы пытаетесь обслуживать.

В Apache это можно настроить в файле виртуального хоста для этого сайта или в файле .htaccess, расположенном в самом каталоге.

Доступ к этим файлам можно ограничить несколькими способами. Каталоги могут быть ограничены следующим образом в Apache 2.4+:

&lt;Directory /usr/share&gt;
    AllowOverride None
    Require all denied
&lt;/Directory&gt;

В Nginx эти ограничения примут форму директив deny и будут расположены в блоках вашего сервера или в основных конфигурационных файлах:

location /usr/share {
    deny all;
}

Если у вас есть серверная часть базы данных, работает ли она?

Если ваш сайт использует серверную базу данных, такую как MySQL, PostgresSQL, MongoDB и т. д., вам необходимо убедиться, что она работает и доступна.

Вы можете сделать это так же, как вы проверяли, работает ли веб-сервер. Опять же, вы можете выполнять поиск по запущенным процессам с помощью netstat и grep:

sudo netstat -plunt | grep mysql

Output
tcp        0      0 127.0.0.1:3306        0.0.0.0:*         LISTEN      3356/mysqld

Как видите, служба запущена на этой машине. При поиске убедитесь, что вы знаете имя, под которым работает ваша служба.

Альтернативой является поиск порта, на котором работает ваша служба. Просмотрите документацию по вашей базе данных, чтобы найти порт по умолчанию, на котором она работает (по умолчанию MySQL — 3356), или проверьте файлы конфигурации.

Если у вас есть серверная часть базы данных, может ли ваш сайт успешно подключиться?

Следующий шаг, который необходимо предпринять, если вы устраняете проблему с серверной частью базы данных, — проверить, можете ли вы правильно подключиться. Обычно это означает проверку файлов, которые читает ваш сайт, чтобы узнать информацию о базе данных.

Например, для сайта WordPress настройки подключения к базе данных хранятся в файле с именем wp-config.php. Вам необходимо проверить правильность DB_NAME, DB_USER и DB_PASSWORD, чтобы ваш сайт мог подключиться к базе данных.

Вы можете проверить, содержит ли файл правильную информацию, попытавшись подключиться к базе данных вручную из командной строки. Большинство баз данных будут поддерживать синтаксис, аналогичный MySQL:

mysql -u DB_USER_value -pDB_PASSWORD_value DB_NAME_value

Если вы не можете подключиться, используя значения, которые вы нашли в файле, вам может потребоваться изменить права доступа к вашим базам данных.

Если ничего не помогает, снова проверьте журналы

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

Если вы исчерпали свои возможности самостоятельно устранять неполадки и вам нужна помощь, вы быстрее получите более актуальную помощь, предоставив файлы журнала и сообщения об ошибках. Опытные администраторы, вероятно, будут иметь хорошее представление о том, что происходит, если вы предоставите им необходимую информацию.

Заключение

Надеемся, что эти советы по устранению неполадок помогут вам отследить и устранить некоторые из наиболее распространенных проблем, с которыми сталкиваются администраторы при попытке запустить свои сайты.

Если у вас есть какие-либо дополнительные советы по проверке и способам решения проблем, поделитесь ими с другими пользователями в комментариях.