Apache (httpd)
Несмотря на то, что мы установили и настроили PHP-FPM, Apache нам понадобится, как минимум, по двум причинам. Во-первых, многие сайты используют файл .htaccess, который читает только Apache. Во-вторых, последний включает большое число модулей, которые может использовать портал.
В некоторых случаях, можно обойтись без Apache, но в данной инструкции мы опишем процедуру его установки и настройки.
И так, устанавливаем httpd:
yum install httpd
Заходим в настройки:
vi /etc/httpd/conf/httpd.conf
И редактируем следующее:
Listen 8080
* наш веб-сервер будет слушать на порту 8080, так как на 80 уже работает NGINX.
<IfModule dir_module>
DirectoryIndex index.php index.html
</IfModule>
* если не указан конкретный скрипт, сначала веб-сервер пытается найти и запустить index.php, затем index.html
Добавляем:
<Directory /var/www/*/www>
AllowOverride All
Options Indexes ExecCGI FollowSymLinks
Require all granted
</Directory>
* где Directory — разрешенные каталоги для запуска из apache; Options — разрешенные опции; Require — с каких IP-адресов можно открывать сайты, определенные в данном каталоге. Итого, мы разрешаем все каталоги в /var/www, но только если следующий каталог будет www; разрешаем опции Indexes (возвращает список файлов, если нет индексного файла, например, index.php), ExecCGI (разрешены сценарии CGI), FollowSymLinks (включены символические ссылки в этом каталоге); доступ для данных каталого разрешен со всех адресов (all granted).
Проверяем синтаксис конфигурационного файла httpd:
apachectl configtest
Разрешаем автозапуск и запускаем службу:
systemctl enable httpd —now
Создаем php-файл со следующим содержимым:
vi /var/www/html/index.php
<?php phpinfo(); ?>
Открываем браузер и вводим в адресную строку IP-адрес нашего сервера и добавляем :8080. Мы должны увидеть привычную страницу:
NGINX + Apache
Ранее нами была настроена связка nginx + php-fpm. Теперь проверяем совместную работу первого с apache.
Открываем конфигурационный файл nginx:
vi /etc/nginx/conf.d/default.conf
* если при настройке nginx мы редактировали файл /etc/nginx/nginx.conf, то необходимо открыть его.
Находим наш настроенный location для php-fpm:
…
location ~ \.php$ {
fastcgi_pass unix:/run/php-fpm/www.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
include fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
}
…
и меняем на:
…
location ~ \.php$ {
proxy_pass http://127.0.0.1:8080;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
…
Проверяем и перезапускаем nginx:
nginx -t
systemctl restart nginx
Пробуем открыть в браузере IP-адрес нашего сервера — должна открыться та же страница, что при проверке Apache (с добавлением 8080):
Apache Real IP
Так как все запросы на httpd приходят от NGINX, они воспринимаются как от IP-адреса 127.0.0.1. На практике, это может привести к проблемам, так как некоторым сайтам необходимы реальные адреса посетителей.
Для решения проблемы будем использовать модуль mod_rpaf. Устанавливаем набор разработчика для apache:
yum install httpd-devel gcc unzip
Переходим в каталог /usr/local/src:
cd /usr/local/src
Скачиваем модуль:
wget https://github.com/gnif/mod_rpaf/archive/stable.zip
Распаковываем его:
unzip stable.zip
Переходим в распакованный каталог:
cd mod_rpaf-stable/
Собираем модуль и устанавливаем его:
make
make install
* при возникновении ошибки ./apxs.sh: line 15: -c: command not found, необходимо поставить which командой yum install which.
Создаем конфигурационный файл со следующим содержимым:
vi /etc/httpd/conf.d/mod_rpaf.conf
LoadModule rpaf_module modules/mod_rpaf.so
RPAF_Enable On
RPAF_ProxyIPs 127.0.0.1
RPAF_SetHostName On
RPAF_SetHTTPS On
RPAF_SetPort On
RPAF_ForbidIfNotProxy Off
Перезапускаем httpd:
systemctl restart httpd
Для проверки настройки открываем на редактирование созданный index-файл для httpd:
vi /var/www/html/index.php
И редактируем содержимое на:
<?php echo $_SERVER ?>
Открываем браузер и вводим в адресную строку IP-адрес нашего сервера. Мы должны увидеть внешний адрес компьютера, с которого обращаемся к серверу.
nginx
Отключим отображение скрытых файлов:
location ~ /\. {
deny all;
}
nginx используется как frontend, и если на нем отдается контент по https, то повышаем его безопасность. Для начала отключаем SSLv3 и другие небезопасные протоколы. Если nginx свежий, то в нем это уже и так отключено, поэтому лучше просто обновиться.
Генерируем параметры обмена ключами Diffie-Hellman (которые могут генерироваться достаточно долго, запаситесь временем)
openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096
и затем подключаем их в энжинксе
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
Можно оставить только сильные шифры, но при этом старые браузеры могут не поддерживаться. Если на совместимость с ними не ориентироваться, то можно смело включать
ssl_ciphers 'AES256+EECDH:AES256+EDH:!aNULL';
Также имеет смысл включить кеширование
ssl_session_cache shared:SSL:10m;
После всех настроек желательно проверить их корректность в каком-нибудь сервисе, например, этом.
Совместное функционирование Apache + Nginx
Рассмотренные характеристики веб-серверов обуславливают выбор в пользу того или иного для каждого конкретного проекта. В некоторых случаях целесообразно использовать связку Apache + Nginx. Последний разворачивается перед Apache для выполнения функций реверс-прокси. За обработку всех входящих запросов отвечает Nginx, способный успешно справляться с их большим количеством. Его основная задача в данной конфигурации – обработка статического контента. Если требуется выполнение, например, PHP-сценариев, запрос поступает на Apache, где происходит его обработка. Полученный результат передается вначале Nginx, а затем – конечному пользователю.
Таким образом, Nginx сортирует запросы на статические и динамические. С первыми он успешно справляется сам, вторые – адресует Apache. Этот подход обуславливает частичное снижение нагрузки на последний.
Связка Apache + Nginx используется для горизонтального масштабирования веб-приложений. Например, возможен вариант подключения нескольких веб-серверов Apache к одному Nginx, распределяющему нагрузку между ними. Подход способствует повышению отказоустойчивости веб-сервисов.
Многие сервисы FREEhost.UA, например виртуальный хостинг, так же используют связку Apache + Nginx. Apache отвечает за работу с динамическим контентом, а Nginx за статический контент. Поскольку веб сервер Nginx находится впереди, проксируя весь трафик на Apache, с его помощью мы фильтруем часть “вредного трафика” во время DDOS атаки и попыток взлома сайтов.
| ПОДОБРАТЬ | ХОСТИНГот 29 грн./мес. |
— 3000 мб диск — почта без ограничений — авто установка CMS — бесплатный домен |
Подходит для размещения персональных и корпоративных сайтов, небольших электронных мгазинов. |
Причины ошибки
Причины, по которым HTTP возвращает ответ 404 Not Found:
- Неверный адрес. К примеру, при ручном наборе пользователь допустил опечатку в URL либо ссылка ведёт на несуществующую страницу.
- Битая ссылка. Это нерабочий URL, который никуда не ведёт. Данный вариант иногда возникает при внутренней перелинковке. К примеру, раньше страница существовала, а потом её удалили и забыли убрать ссылку.
- Удалённая страница. Когда пользователь попытается перейти на удалённую с сервера страницу, он также увидит ошибку 404. Ссылка для перехода может сохраниться в браузерных закладках или на сторонних ресурсах.
- Неправильный редирект на страницу с изменённым адресом. Допустим, в процессе редизайна URL изменили, но оставили без внимания связанные ссылки.
- Неполадки на сервере. Это самый редкий вариант.
В большинстве ситуаций ошибка 404 отображается, когда не удаётся обнаружить нужную страницу на доступном сервере.
Причины отсутствия страницы на сайте бывают разными
Балансировщик нагрузки Nginx
Если вы собираетесь получать много трафика, то вам, вероятно, захочется настроить балансировщик нагрузки для использования с настройкой php-fpm.
Обычно мы хотим запустить несколько бэкенд серверов на верхнем уровне, все из которых работают с зеркалами вашего блога, а затем еще один сервер, на котором работает nginx, который действует как балансировщик нагрузки и будет направлять нагрузку между потоками трафика.
Это означает, что вы можете использовать много серверов для одновременного доступа к вашему блогу, а конфигурация для этого относительно проста.
Примерная конфигурация будет выглядеть так. Сначала мы начинаем с модуля upstream:
Здесь каждый backend1.example.com имеет собственную конфигурацию Nginx, зеркало того, как сайт был до того, как он имел балансировщик нагрузки. Nginx будет выбирать, какой сервер использовать для каждого запроса.
Если у одного из наших бэкендов есть более быстрый жесткий диск, например SSD, или географически ближе к вашей основной пользовательской базе, вы можете установить вес так:
Кроме того, если вы считаете, что сервер может стать медленнее или вы беспокоитесь о тайм-аутах, то для этого тоже есть варианты конфигурации:
Теперь, с этой конфигурацией, после 3 сбоев или 15-секундного таймаута сервер больше не будет использоваться балансировщиком нагрузки. Если вы хотите вручную пометить сервер как неактивный, добавьте ключевое слово например так: .
Затем нам нужно передать это серверу через прокси-сервер, используя upstream, который мы только что определили ранее:
Теперь перезагрузите сервер с помощью , и вы запускаете балансированную по нагрузке версию своего сайта!
Наконец, по этой теме, также для вашей справки приведено руководство nginx по обслуживанию статического содержимого и наилучшим параметрам конфигурации
Обратите внимание на использование и для Mp3, например
Шаг #4: Создание и настройка сервер-блоков Nginx
Для создания возможности обработки нескольких доменов на одном ip-адресе, веб-сервер Apache использует виртуальные хосты — это специальные файлы конфигурации веб-сервера, которые настраиваются отдельно для каждого домена. В веб-сервере Nginx также присутствует такая возможность, однако в терминологии Nginx виртуальные хосты называются сервер-блоками.
Создание директорий для сайта
По умолчанию, Nginx создает один сервер-блок настроенный для обработки файлов из директории , однако для создания самостоятельных сервер-блоков для каждого отдельного домена рекомендуется использовать директорию . Внутри каталога создадим новый каталог с именем вашего домена, внутри которого также добавим нужные подкаталоги — , где будут хранится файлы сайта и , где будут хранится логи работы веб-сервера.
Созданным директориям нужно присвоить владельца. Владельцем чаще всего назначается сам веб-сервер т.к. именно он проводит большинство операций с файлами.
Установка веб-сервера в качестве владельца особенно важна при установки каких-либо CMS-систем, например WordPress.
Так как нашим веб сервером будет Nginx, то и установим его в качестве владельца и группы. При необходимости группу можно будет заменить на любую удобную вам.
Также настроим права доступа для
Создание тестовой страницы.
Для проверки работоспособности будущего сервер-блока создадим главную страницу сайта — . При желании, вы можете создать полноценную html-разметку, однако я ограничусь простым текстом, которым заполню файл с помощью команды — echo.
Создание сервер-блока
Изначально Nginx содержит только один сервер-блок с именем — , его мы будет использовать в качестве шаблона для наших собственных сервер-блоков.
Создадим необходимые для работы каталоги и файл для настроек сервер-блока:
Файл может содержать следующие настройки:
server {
listen 80;
server_name example.ru www.example.ru;
set $root_path ‘/var/www/example.ru/www’;
root $root_path;
index index.php index.html;
location / {
try_files $uri $uri/ $uri.html $uri.php$is_args$query_string;
}
error_page 500 502 503 504 /50x.html;
error_page 404 /404.php;
location = /50x.html {root /usr/share/nginx/html;}
#location = /404.php {root $root_path;}
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $request_filename;
include fastcgi_params;
fastcgi_intercept_errors on;
}
error_log /var/www/example.ru/log/nginx-error.log error;
}
|
1 |
server{ listen80; server_name example.ruwww.example.ru; set$root_path’/var/www/example.ru/www’; root$root_path; index index.phpindex.html; location{ try_files$uri$uri$uri.html$uri.php$is_args$query_string; } error_page50050250350450x.html; error_page404404.php; location=50x.html{rootusrsharenginxhtml;} #location = /404.php {root $root_path;} location~\.php${ fastcgi_pass127.0.0.19000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME$request_filename; include fastcgi_params; fastcgi_intercept_errors on; } error_logvarwwwexample.rulognginx-error.logerror; } |
Включение сервер-блоков
Теперь когда созданы сервер-блоки их нужно активировать, чтобы Nginx мог начать с ними работать.
Сделать это можно путем создания символической ссылки:
Убедитесь, что все конфигурационные файлы, для каждого домена, подключены в главном конфиге Nginx. Для этого в файле должна присутствовать следующая строка.
Теперь, если все предыдущие этапы выполнены без ошибок, то вы можете зайти на страницу сайта, введя имя домена в адресную строку, в моем случае это example.ru.
Nginx выдал страницу для сайта example.ru
Как исправить «404 Not Found Nginx»?
1. Регулярные выражения
Как я уже сказал выше, самой частой проблемой, которая вызывает 404, являются регулярные выражения. Смотрим, что происходит в лог файле:
Видим, что серверу пришёл запрос /vstats. Дальше он проверяет location: /, /robots.txt, /vatsts/, /site-control/. Здесь уже можем понять, в чём проблема — промазали на один слеш. Дальше проверяются все регулярные выражения, и, так как в них ничего найдено не было, выбирается location /.
Далее директива try_files пытается найти файл /vstats, не находит и ищет index.php, который, в свою очередь, возвращает 404.
Если мы наберём, то что ожидает видеть Nginx — /vstats/, то откроется наша страница статистики.
Если мы добавим к конфигурационному файлу ещё один location с регулярным выражением, например:
То абсолютно все запросы будут обрабатываться именно этим регулярным выражением и, естественно, что ничего работать не будет. Видим, что приходит запрос /vstats/:
Он совпадает с префиксным location, но потом Nginx видит наше регулярное выражение и передаёт управление ему.
Поэтому будьте очень осторожны с регулярными выражениями, если они вам нужны, то размещайте их только внутри префиксных location, чтобы ограничить их область действия этим location, иначе может возникнуть ошибка 404 nginx.
2. Недостаточно памяти
Если php-скрипту не хватило оперативной памяти для выполнения, и его процесс был убит операционной системой, то Nginx тоже может вернуть ошибку 404. Такое поведение вы будете наблюдать, когда скрипт очень долго выполняется, а потом появляется «404 Not Found» или страница ошибки вашего движка. Обычно эта неисправность тоже видна в отладочном логе.
Решить такую проблему можно, освободив память на сервере, часто такое может возникать из-за утечек памяти в php, когда процессы php-fpm занимают почти всю память на сервере. Поэтому перезапуск php-fpm решает проблему:
Чтобы избежать этой проблемы в будущем, можно настроить автоматический перезапуск процессов после обработки определённого количества запросов. Например каждые 200 запросов:
3. Не найден index
Если вы запрашиваете URL вида /vstats/, но в настройках Nginx не указан файл index, который нужно использовать для этой ссылки, то у вас ничего не выйдет, и вы получите 404. Вы можете добавить директиву index в ваш location:
Или сразу в server, в Nginx все location наследуют директивы, установленные в server.
4. Другие проблемы
Подобных проблем, вызывающих 404 в Nginx, может быть очень много, но все они решаемы, и всё, что нужно для их решения, есть в отладочном логе Nginx. Просто анализируйте лог и на основе этого вносите исправления.
Конфликт с «Рамблером»
В 2019 году произошла такая история: Рамблер заявил, что раз Сысоев во время создания Nginx работал у них, то и все права на этот веб-сервер тоже принадлежат им. В итоге завели дело по статье о нарушении авторских прав, а Рамблер требовал возместить им ущерб в 50 миллионов рублей.
Через полгода уголовное дело прекратили за отсутствием состава преступления: компания не смогла найти подтверждения своим словам и не смогла получить права на код Nginx.
По иронии судьбы на Nginx сейчас работают серверы и самого Рамблера
Текст:
Михаил Полянин
Редактор:
Максим Ильяхов
Художник:
Даня Берковский
Корректор:
Ирина Михеева
Вёрстка:
Кирилл Климентьев
Соцсети:
Олег Вешкурцев
Шаг 2 — Установка MySQL
Мы запустили веб-сервер, и теперь нам нужно установить СУБД, которая может хранить данные вашего сайта и управлять ими. MySQL — популярная СУБД, используемая в средах PHP.
Используйте для получения и установки этого программного обеспечения:
Для подтверждения установки введите , а затем нажмите .
После завершения установки рекомендуется запустить скрипт безопасности, предустановленный в MySQL. Этот скрипт будет удалять некоторые небезопасные настройки по умолчанию и блокировать доступ к системе управления базы данных. Для запуска интерактивного скрипта введите следующую команду:
Скрипт предложит настроить плагин .
Примечание. Эту функцию следует активировать при наличии разумных оснований. Если она активирована, MySQL будет отклонять пароли, не соответствующие определенным критериям, и выводить сообщение об ошибке. Оставить проверку отключенной достаточно безопасно, но для входа в базу данных всегда нужно использовать надежные уникальные пароли.
Выберите для активации или любой другой вариант, чтобы продолжить без активации этой функции.
Если вы ответите утвердительно, вам будет предложено выбрать уровень проверки пароля. Если вы укажете самый высокий уровень , система будет выводить сообщения об ошибке при попытке установки пароля, который не будет содержать цифры, буквы в верхнем и нижнем регистре и специальные символы или будет содержать распространенные словарные слова.
Вне зависимости от того, будете ли вы использовать плагин , ваш сервер предложит вам выбрать и подтвердить пароль для пользователя root в MySQL. Не нужно путать его с системным пользователем root. Пользователь root базы данных — это пользователь с правами администратора, который имеет все права для работы с системой управления базы данных. Хотя в MySQL метод аутентификации пользователя root по умолчанию не требует использования пароля даже при его наличии, задайте надежный пароль для обеспечения дополнительной безопасности. Чуть дальше мы расскажем об этом подробнее.
Если вы включили использование паролей, вы увидите уровень надежности введенного пароля root, и ваш сервер запросит у вас подтверждение дальнейшего использования этого пароля. Если вас устраивает текущий пароль, введите в диалоге для подтверждения:
Для всех остальных вопросов нужно выбирать и нажимать в каждом диалоге. Выбрав эти ответы, вы удалите ряд анонимных пользователей и тестовую базу данных, отключите возможность удаленного входа пользователя root и загрузите новые правила, чтобы внесенные изменения немедленно активировались в MySQL.
Завершив настройку, проверьте возможность входа в консоль MySQL, набрав следующую команду:
В результате будет установлено подключение к серверу MySQL с помощью пользователя root базы данных с правами администратора, который логически выводится в результате использования при запуске данной команды. Результат должен выглядеть следующим образом:
Для выхода из консоли MySQL введите следующую команду:
Обратите внимание, что для подключения под именем пользователя root не требуется вводить пароль, хотя вы и задали его при запуске скрипта. Это происходит, поскольку используемый по умолчанию метод аутентификации для пользователя MySQL с правами администратора — , а не
Хотя это может выглядеть как возможный источник проблем с безопасностью, на самом деле эти действия делают сервер базы данных более защищенным, поскольку единственные пользователи, которые могут выполнять вход в систему с правами доступа root для MySQL — это пользователи системы с привилегиями sudo, подключенные с использованием консоли или через приложение, использующее аналогичные привилегии. На практике это означает, что вы не сможете использовать пользователя root базы данных с правами администратора для подключения из вашего приложения PHP. Настройка пароля учетной записи root MySQL работает как гарантия, если метод аутентификации по умолчанию меняется с на .
Для дополнительной безопасности рекомендуется иметь специальные учетные записи пользователей с менее обширными привилегиями, особенно если вы планируете использовать несколько баз данных на сервере.
Примечание. На момент написания этого руководства родная библиотека MySQL PHP не поддерживает , метод аутентификации MySQL 8 по умолчанию. Поэтому при создании пользователей базы данных для приложений PHP на MySQL 8 вам нужно убедиться, что вместо этого пароля они настроены на использование . Мы расскажем об этом в .
Теперь ваш сервер MySQL установлен и защищен. Далее мы выполним установку PHP, последнего компонента стека LEMP.
Как устранить ошибку
Теперь к вопросу о том, как исправить ошибку, которая именуется как 404 Not Found.
Фактически тут есть 2 варианта, в зависимости от того, с чьей стороны смотреть на ситуацию:
- обычного пользователя;
- владельца сайта.
Будучи обычным пользователем, который заходит на сайт, но сталкивается с таким кодом, способов решения проблемы не так много.
Тут есть следующие рекомендации о том, как убрать ошибку 404, дополненную обычно надписью Not Found:
- проверить адрес введённой ссылки на наличие возможных ошибок, опечаток;
- попробовать ввести тот же адрес ещё раз;
- перезагрузить страницу, которая не отображается;
- вернуться на страницу назад и ещё раз попробовать перейти на требуемый раздел.
Но чаще всего проблема со стороны самого сайта. И её предстоит исправлять веб-мастеру. Пока он её не обнаружит и не откорректирует, открыть страницу по этой ссылке не получится.
Создание проекта Django
Теперь нужно создать два виртуальных окружения и запустить два проекта.
Создание первого проекта Django
Создайте виртуальное окружение с помощью команд, доступных благодаря инструменту virtualenvwrapper.
Чтобы создать первое виртуальное окружение, введите:
Эта команда создаст виртуальное окружение по имени firstsite, а также установит локальную версию Python и pip, которые можно использовать для создания изолированной среды разработки проекта. Командная строка изменится, указывая, что текущей средой является виртуальная среда Python
В скобках указано имя текущего виртуального окружения. Теперь всё программное обеспечение, загруженное с помощью pip, будет установлено в индивидуальное окружение первого проекта и никак не повлияет на общее состояние системы.
Сначала нужно установить Django:
Теперь создайте первый тестовый проект:
Эта команда создаст в домашнем каталоге каталог firstsite. В нём хранится сценарий для управления новым проектом и ещё один одноимённый каталог, в котором будет находиться код проекта.
Откройте каталог первого уровня:
Для начала нужно переместить БД, чтобы инициализировать базу данных SQLite для проекта.
Примечание: При желании можно создать базу данных для приложения самостоятельно, но это выходит за рамки данного руководства.
Теперь в домашнем каталоге есть файл БД по имени db.sqlite3. Создайте администратора.
Выберите имя пользователя, укажите контактный адрес электронной почты, а затем выберите и подтвердите пароль.
Затем откройте файл настроек проекта:
Теперь нужно создать отдельный каталог для хранения статических файлов сайта. Так Nginx сможет обслуживать их напрямую, а это улучшит производительность. Поместите каталог static в корневом каталоге проекта. Добавьте в конец конфигурационного файла следующую строку:
Сохраните и закройте файл. Соберите статические файлы в этом каталоге:
В каталоге проекта появится новый каталог static.
Теперь протестируйте проект, временно запустив сервер разработки.
Это запустит сервер разработки на порт 8080. В браузере посетите свой домен или IP:
На экране должна появиться такая страница:
Добавьте в ссылку сегмент /admin, чтобы получить доступ к форме аутентификации администратора. Введите учётные данные администратора, и на экране появится панель управления.
После этого можно остановить сервер разработки. Нажмите CTRL-C в терминале. Теперь можно приступать к разработке второго проекта.
Разработка второго проекта
Второй проект создаётся точно так же, как первый.
Вернитесь в домашний каталог и создайте второе виртуальное окружение. Установите Django.
После этого откроется окружение нового проекта.
Создайте второй проект и откройте его каталог:
Инициализируйте базу данных и создайте пользователя с правами администратора:
Откройте файл settings:
Добавьте каталог статических файлов строку:
Сохраните и закройте файл. Соберите статические файлы в этот каталог.
Запустите сервер разработки:
Ссылка на интерфейс администратора:
Чтобы остановить сервер, нажмите CTRL-C.
Отключение виртуального окружения
Теперь нужно отключить виртуальное окружение, поскольку разработка проектов завершена:
Чтобы вернуться в виртуальное окружение любого из проектов, введите:
В дальнейшей работе виртуальное окружение не нужно, потому отключите его:
Что означает ответ 404
Error 404 Not Found отображается по-разному: «HTTP 404 не найден», «Ошибка 404 Not Found», «404 Страница не найдена». Смысл надписи всегда остаётся тем же: страница отсутствует либо просто не работает. Not Found в переводе означает «не найдено».
Ошибка 404 — классический код ответа по протоколу HTTP. Он свидетельствует, что связь с сервером установлена, но информации по заданному запросу нет.
Однако если просто ввести в поисковую строку произвольный набор символов, то браузер не покажет ошибку 404 Not Found — появится сообщение, что установить соединение с конкретным сервером невозможно.
Разберёмся в техническом формировании ответа Error 404 Not Found.
Техническая сторона вопроса. При связи по HTTP браузер запрашивает указанный URL и ждёт цифрового ответа. То есть любой запрос пользователя направляется на сервер размещения искомого сайта. Когда браузеру удаётся связаться с сервером, он получает кодированный ответ. Если запрос корректный и страница найдена, отправляется ответ с кодом 200 OK, что соответствует благополучной загрузке. При отсутствии страницы отправляется ответ об ошибке.
Что значит код «404». В ответе 404 первая четвёрка указывает на то, что запрос был чрезмерно длительным или в самом адресе была ошибка. Ноль предполагает синтаксическую неточность. Завершающая цифра кода отображает конкретную причину ошибки — «4» означает отсутствие данной ссылки.
Какие ещё ошибки бывают. Ошибку 404 не нужно путать с другими ответами, которые указывают на невозможность связи с сервером. Например, ошибка 403 сообщает, что доступ к URL ограничен, а ответ «Сервер не найден» свидетельствует, что браузер не смог обнаружить место размещения сайта.
Google на 404 странице сообщает о возможных причинах ошибки
Настройка Apache для использования mod_fastcgi
По умолчанию Apache обслуживает страницы PHP с помощью , однако для работы с PHP-FPM ему требуется дополнительная настройка.
Примечание. Если вы пытаетесь использовать это обучающее руководство в существующей системе LAMP с mod_php, вначале выполните отключение с помощью команды .
Мы добавим блок конфигурации для зависящий от . По умолчанию отключен, и предварительно его нужно включить:
Переименуйте существующий файл конфигурации FastCGI:
Создайте новый файл конфигурации:
Добавьте в файл следующие директивы для передачи запросов файлов в сокет PHP-FPM UNIX:
/etc/apache2/mods-enabled/fastcgi.conf
Сохраните изменения и проведите тест конфигурации:
Если отображается Syntax OK, перезагрузите Apache:
Если отображается предупреждение , его можно игнорировать. Мы настроим имена серверов позднее.
Теперь убедимся, что мы можем обслуживать PHP из Apache.
apache2
Отключаем потенциально опасные и просто неиспользуемые модули, а также неиспользуемые подконфиги. Почти всегда можно (и нужно) отключить:
- модуль autoindex, позволяющий просматривать содержимое директории при отсутствии индексного файла,
- обработку cgi-bin, которая в deb-based системах лежит в конфиге и используется очень редко,
- Другие неиспользуемые модули (список которых зависит от выкладываемого кода). Т.е. необходимо перешерстить директории ,
На продакшн-сервере пользователю не нужно знать точную версию апача. Вообще, подобной информации должно отдаваться как можно меньше. Формат этой информации регулируется параметром , который по умолчанию обычно выставлен в и в результате веб-сервер выдает что-то вроде
Apache/2.4.10 (Debian) Server at ...
Этот параметр, как и некоторые другие настройки безопасности в debian-системах обычно находится в конфиге . Переключаем в менее информативную и, соответственно, более безопасную версию:
#ServerTokens Minimal #ServerTokens OS #ServerTokens Full ServerTokens Prod
Аналогичным образом стоит поступить с подписью сервера на «ошибочных» страницах
ServerSignature Off #ServerSignature On
и трассировкой
TraceEnable Off
Последняя обычно уже отключена, но в этом необходимо убедиться.
Код некоторых выкладываемых сайтов может содержать скрытые файлы, вроде , и других, раскрывающих стуктуру кода. Их желательно отключить здесь же, в апаче, или в фронт-энде. Можно отключить сразу все скрытые файлы:
<DirectoryMatch "/\."> Require all denied </DirectoryMatch>
Полезную информацию можно также подчерпнуть из первоисточников: апачевского, дебиановского. При этом, последняя статья несколько выходит за пределы настроек самого апача.
Некоторые из правил для бэкэнда закрывают те же места, что и в фронтэнде. Даже если каким-то образом будет поломана конфигурация nginx, уязвимость все равно не реализуется.
Отключим доступ к скрытым файлам — в секции виртуалхоста добавляем:
RedirectMatch 404 /\..*$
Такие файлы нередко встречаются в проектах. В частности, системы контроля версий вроде , . Эта метаинформация не должна попадать в прошакш, тем не менее следует превентивно защититься от такой возможности.
Если VirtualHost на сервере не один, то также не плохо будет раскомментировать секцию
AllowOverride None Order Deny,Allow Deny from all
которая отключает доступ ко всем файлам из корня. Естественно, чтобы виртуалхост работал нужно включить доступ к самой директории виртуалхоста по типу
AllowOverride All Order Deny,Allow Allow from all
Я не описываю настройку прав доступа (пользователь:группа) на уровне ОС и файловой системы и использование модуля с директивой . Это тоже должно быть сделано для серверов, на которых такое разделение требуется.
Поиск битых ссылок на сайте
Если вы являетесь владельцем сайта, можно проверить наличие битых ссылок и удаленных страниц при помощи специальных онлайн-сервисов или программ. Существует несколько популярных инструментов, о которых и пойдет речь далее.
Яндекс.Вебмастер
Проще всего использовать сайт Яндекс.Вебмастер. Потребуется авторизоваться в сервисе и добавить собственный сайт, выполнив простые инструкции, которые будут отображаться на экране. После этого выполните такую последовательность действий:
- Через левое меню откройте раздел «Индексирование».
- Там вас интересует категория «Страницы в поиске».
- Снизу перейдите на вкладку «Исключительные страницы».
- Задайте фильтрацию, чтобы сначала отображались результаты, где присутствует «ошибка 404: страница не найдена».
Google Search Console
Онлайн-сервис от известной компании Google Search Console функционирует примерно по такому же принципу, а для поиска проблемных страниц пользователю потребуется выполнить следующие действия:
- Выполните вход и добавьте свой сайт.
- Откройте раздел «Сканирование».
- Перейдите к категории «Ошибки сканирования».
- Используйте фильтр или самостоятельно ознакомьтесь с присутствующими ошибками.
Screaming Frog
Screaming Frog – специализированное программное обеспечение, подходящее для сканирования сайтов. Если приведенные выше онлайн-сервисы вам не подошли, скачайте это решение с официального сайта, подключите к нему ваш сайт и произведите сканирование.
Благодаря данному инструменту у вас получится легко обнаружить все проблемные страницы, в том числе и страницы с другими ошибками сервера.
В чём ещё отличия от Apache
Документация. У Apache документации, форумов и примеров гораздо больше, потому что проект начался на 7 лет раньше и все материалы сразу были на английском — стандартном языке для всех программистов.
Nginx появился позже и в России, поэтому почти вся документация изначально была на русском. Из-за этого разработчикам из других стран было трудно использовать Nginx, но со временем ситуация выровнялась: сейчас проект ведётся одновременно на русском и на английском языках.
Работа с модулями. В Apache всё просто: прописал название модуля и веб-сервер сразу его подгрузил и начал использовать. Не нужно — выгрузил, тоже на ходу. Это позволяет очень гибко настраивать поведение сервера в разные моменты времени.
Чтобы добавить модули в Nginx, их нужно выбрать заранее и скомпилировать вместе с ядром сервера. С одной стороны, это неудобно: нужно на старте чётко представлять, что будет делать сервер и в каких ситуациях. Но с другой — это повышает безопасность: не получится на лету подключить какой-то неизвестный и непроверенный модуль, в котором будет дыра в безопасности.
Конфигурация и настройка. Apache управляется через служебные файлы, в которые он постоянно заглядывает, например .htaccess. Это снова гибкость и возможность очень тонкой настройки поведения для каждой папки и запроса. Но Apache каждый раз тратит время на такие чтения и проверки, а когда запросов много, то это становится критично. Ещё нужно просмотреть все папки, к которым идёт запрос, а это тоже время.
Nginx работает иначе: всё хранится в одном конфигурационном файле. Этот файл отвечает за настройки всего сервера, и Nginx точно знает, где его быстро найти. Это более безопасно для работы сервера: никто не сможет положить в папку свой файл .htaccess, прописать в нём чёрт-те что и сломать работу всего сервера.
