|
|
|
||||||
|
|
||||||||
|
|
|
|
||||||
|
|
||||||||
В данной статье разберем самые частые ошибки, появляющиеся в браузере при открытии домена и пути их самостоятельного решения.
Содержание |
Debian/Ubuntu/Centos:
/var/www/httpd-logs/<ваш_сайт>.error.log
Debian/Ubuntu:
/var/log/apache2/error.log
Centos:
/var/log/httpd/error_log
Debian/Ubuntu/Centos:
/var/log/nginx/error.log
Debian/Ubuntu:
/etc/init.d/apache2 start
Centos:
/etc/init.d/httpd start
Debian/Ubuntu/Centos:
/etc/init.d/nginx start
Необходимо убедиться в том, что ваш домен ведет на нужный вам IP. Для этого проверьте работу серверов имён
Распространенные причины, почему появляется данное сообщение:
1. домен создан, но кэш DNS еще не обновился. Обновление занимает от 2 до 72 часов.
При смене IP-адреса сайта в ISPmanager - WWW домены нужно также менять IP и в пункте "Доменные имена". Затем необходимо обновить домен на внешних серверах имен кнопкой в виде аптечки "Обновить".
2. В пункте "WWW домены" в настройках домена в графе "Индексная страница" указано имя файла, отсутствующего на сервере (в таком случае по домену может также выводиться страница "Index of ...". Данное поле можно оставлять пустым: в таком случае откроется страница index.html, если ее нет - index.php.
3. Важно, чтобы все файлы CMS и сайта были загружены в директорию вашего домена /www/имя_домена.
В остальных случаях необходимо подробно разбираться в конфигурационном файле.
Сервер не пингуется, но необходимо оперативно восстановить работу сервера - перезагрузите сервер. Это можно сделать, зайдя в Личный кабинет(BILLmanager)=>"Товары/Услуги"=>"Виртуальные сервера"=>Выделяете нужный продукт=>Кнопка "В панель"
в правом верхнем углу:
VMmanager/VEmanager:
"Управление"=>"Виртуальные машины"=>Выделить нужный сервер=>Кнопка "Перезапуск"
Если сайты не открываются, то попробуйте открыть панель управления ISPmanager по ссылке:
https://<IP_вашего_сервера>:1500/ispmgr
Панель ISPmanager 5=>Система=>Службы=>В строках nginx и httpd должны быть включены лампочки, если лампочки не горят, то выделить нужное имя процесса=> Кнопка "Старт"
Если Web-сервер не запускается, то нужно запустить его вручную через консоль, подключившись по ssh.
Возможные ошибки при запуске Apache, которые вы увидите в консоле:
apache2: bad user name usertest
Это значит, что в конфиге Apache в директиве SuexecUserGroup или AssignUserID прописан пользователь usertest, которого не существует. Для решения проблемы нужно указать пользователя, который есть на сервере или полностью закомментировать проблемный VirtualHost, добавив в начало каждой строки символ #. Директивы SuexecUserGroup или AssignUserID имеют одинаковую функцию - указывают владельца домена. Но какую директиву использовать, зависит от вашего Apache.
Apache-mpm-ITK указать AssignUserID
Apache-mpm-Prefork указать SuexecUserGroup
Узнать, какая версия Apache у вас установлена, можно, выполнив команду:
apache2ctl -V | grep -i 'Server MPM'
или
apachectl -V | grep -i 'Server MPM'
Вот пример конфига:
<VirtualHost 127.0.0.1:80 >
ServerName domain.ru
CustomLog /var/www/httpd-logs/1.rootina.fvds.ru.access.log combined
DocumentRoot /var/www/user/data/www/1.rootina.fvds.ru
ErrorLog /var/www/httpd-logs/domain.ru.error.log
ServerAdmin webmaster@domain.ru
ServerAlias www.domain.ru
SuexecUserGroup usertest user
AddType application/x-httpd-php .php .php3 .php4 .php5 .phtml
AddType application/x-httpd-php-source .phps
php_admin_value open_basedir "/var/www/user/data:."
php_admin_value sendmail_path "/usr/sbin/sendmail -t -i -f webmaster@domain.ru"
php_admin_value upload_tmp_dir "/var/www/user/data/mod-tmp"
php_admin_value session.save_path "/var/www/user/data/mod-tmp"
</VirtualHost>
После внесения изменений в конфигурационный файл Apache, для вступления в силу этих изменений, нужно перезапустить веб сервер.
Syntax error on line 310 of /etc/apache2/apache2.conf: Invalid command 'helpers', perhaps misspelled or defined by a module not included in the server configuration
Следом за Syntax error идёт пояснение, в какой именно команде вы допустили ошибку. Для решения проблемы, вам нужно открыть файл, упомянутый в полученной ошибке - не обязательно основной конфиг Apache, это может быть также любая из его инклудок, файл, в котором допущена ошибка указан в самой ошибке. В данном примере нужно зайти в файл /etc/apache2/apache2.conf и в строке 310 найти команду helpers. В данном случае этой функции не существует, поэтому для решения проблемы необходимо закомментировать строку, добавив в ее начало символ # .
Invalid command 'php_admin_value', perhaps misspelled or defined by a module not included in the server configuration
Для устранения проблемы вам стоит:
1) Проверить, установлен ли на вашем сервере PHP командой:
php -v
Если он установлен, то получите примерно такой ответ:
PHP 5.3.3 (cli) (built: Dec 11 2013 03:29:57) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
2) Проверить, подключен ли модуль PHP для Apache. Это можно сделать, выполнив команду:
Debian\Ubuntu:
grep -R -i "LoadModule php5_module" /etc/apache2/
Вывод должен быть примерно таким:
# grep -R -i "LoadModule php5_module" /etc/apache2/ /etc/apache2/mods-available/php5.load:LoadModule php5_module /usr/lib/apache2/modules/libphp5.so /etc/apache2/mods-enabled/php5.load:LoadModule php5_module /usr/lib/apache2/modules/libphp5.so
Обратите внимание, что на Debian/Ubuntu модуль будет действительно подключен, только если он подключен из директории mods-enabled - вторая строчка вывода из примера
Centos:
grep -R -i "LoadModule php5_module" /etc/httpd/
Вывод должен быть примерно таким:
# grep -R -i "LoadModule php5_module" /etc/httpd/ /etc/httpd/conf.d/php.conf.rpmsave: LoadModule php5_module modules/libphp5.so /etc/httpd/conf.d/php.conf.rpmsave: LoadModule php5_module modules/libphp5-zts.so /etc/httpd/conf.d/php.conf: LoadModule php5_module modules/libphp5.so /etc/httpd/conf.d/php.conf: LoadModule php5_module modules/libphp5-zts.so /etc/httpd/conf.d/php.conf: LoadModule php5_module modules/libphp5.so
Обратите внимание, что модуль должен быть прописан в файле /etc/httpd/conf.d/php.conf для нужной версии Apache:
Для Apache-Prefork:
<IfModule prefork.c> LoadModule php5_module modules/libphp5.so </IfModule>
Для Apache-ITK:
<IfModule itk.c> LoadModule php5_module modules/libphp5.so </IfModule>
Обращаю ваше внимание на то, что это строка может быть закомментирована символом "#".
Пример ответа, где модуль закомментирован:
/etc/apache2/mods-enabled/php5.load:#LoadModule php5_module libexec/apache22/libphp5.so
Нужно зайти в файл /etc/apache2/mods-enabled/php5.load и удалить "#".
3) Установить нужный модуль на ваш сервер:
Debian/Ubuntu:
apt-get install libapache2-mod-php5
Для Centos модуль ставится вместе с PHP. Если PHP у вас установлен, то стоит проверить, есть ли на вашем сервере библиотека php командой:
ls /etc/httpd/modules/libphp5.so
Если этот файл есть вывод будет такой:
# ls /etc/httpd/modules/libphp5.so /etc/httpd/modules/libphp5.so
Если библиотека есть, значит нужно прописать настройку в файл /etc/httpd/conf.d/php.conf как указано выше.
Для установки PHP используйте команду:
yum install php
Если сайт работает, но иногда открывается слишком медленно или некоторые картинки сайта не подгружаются, то стоит смотреть логи вашего сервера. Разберём частые ошибки, которые вы можете увидеть в логах:
После внесения изменений в конфигурационный файл Apache, для вступления в силу этих изменений, нужно перезапустить веб сервер.
server reached MaxClients setting, consider raising the MaxClients setting
Превышен лимит одновременных подключений, в этом случае лучше сначала выявить причину возникновения ошибки. Простое увеличение параметра - это не самый оптимальный выход из ситуации. Оптимальное значение MaxClients можно рассчитать по следующему принципу:
(M-30%)/H=MaxClients
где M – физическая память на сервере, 30% - память для других процессов, H – память занимаемая одним httpd процессом
К примеру, если у вас установлено 2 Гб физической памяти и один httpd процесс съедает 35 Мб, то (2048-30%)/35=40,96 (округлим в меньшую сторону до 40),т.е. 40 это максимальное количество httpd процессов, при котором будет гарантирована стабильная работа сервера.
Изменить MaxClients вы можете в файле:
Debian/Ubuntu:
/etc/apache2/apache2.conf
Для Apache ITK, модуль по умолчанию не прописан, поэтому MaxClients по умолчанию равен 256 одновременный подключений. Для изменения этой директивы нужно прописать:
<IfModule mpm_itk_module> StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients <Нужное значения> MaxRequestsPerChild 0 </IfModule>
Для Apache Prefork нужно поменять значения в секции:
<IfModule mpm_prefork_module> StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients <Нужное значения> MaxRequestsPerChild 0 </IfModule>
Centos:
/etc/httpd/conf/httpd.conf
Для Apache ITK, модуль по умолчанию не прописан, поэтому MaxClients по умолчанию равен 256 одновременный подключений. Для изменения этой директивы нужно прописать:
<IfModule itk.c> StartServers 8 MinSpareServers 8 MaxSpareServers 10 MaxClients <Нужное значение> MaxRequestsPerChild 1000 </IfModule>
Для Apache Prefork нужно поменять значения в секции:
<IfModule prefork.c> StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients <Нужное значения> MaxRequestsPerChild 0 </IfModule>
После внесения изменений в конфигурационный файл Apache, для вступления в силу этих изменений, нужно перезапустить веб сервер.
Fatal error: Out of memory
Эта ошибка говорит о том, что во время выполнения запроса на сервере закончилась оперативная память. В этом случае нужно смотреть, что именно заняло всю оперативную память. Если это процессы Apache, то советую уменьшить MaxClients для сервера. Подробнее об этом выше.
Возможные ошибки во время запуска:
Restarting nginx: nginx: [emerg] unknown directive "Basic" in /etc/nginx/nginx.conf:13 nginx: configuration file /etc/nginx/nginx.conf test failed
Нужно зайти в конфигурационный файл, путь до которого указан в тексте ошибки, найти нужную строку (прописана после пути) и исправить или закомментировать неизвестную директиву. В данном случае необходимо зайти в файл /etc/nginx/nginx.conf, в строке 13 найти "Basic" и закомментировать все лишнее, установив в начале строки символ #.
nginx: [emerg] could not build the server_names_hash, you should increase either server_names_hash_max_size: 512 or server_names_hash_bucket_size:64
Ошибка возникает, если задано большое количество имён серверов или слишком длинное имя одного из доменов. По умолчанию ограничение равно 32. Для устранения ошибки необходимо уменьшить длину имени домена/поддомена либо увеличить значение директивы:
server_names_hash_bucket_size 128; server_names_hash_max_size 1024;
nginx: [emerg] bind() to 128.11.11.11:80 failed (49: Can't assign requested address)
Данная ошибка означает, что в конфигурационном файле прописан IP адрес 128.11.11.11, которого нет на интерфейсе вашего сервера. Через панель сменить IP адрес для домена не получится, нужно изменить его вручную в конфигурационном файле.
Для этого в конфигурационном файле Nginx в секции server для проблемного домена укажите верный IP адрес. Если домена нет в конфигурационном файле Nginx, то пересоздайте его через панель ISPmanager---WWW(Web)-домены.
Эта ошибка может возникнуть, если А-запись домена ведёт на один IP адрес, а в конфигурационном файле Web-сервера прописан другой, либо домен не создан вообще. В первом случае стоит посмотреть в конфигурационном файле Apache, какой IP прописан для VirtualHost, во-втором - пересоздать домен через панель ISPmanager. Если на сервере стоит связка Nginx+Apache, то также нужно сделать необходимые настройки в конфигурационном файле Nginx.
Стоит проверить секцию server для домена, в строке listen должен быть указать правильный IP адрес. В случае, если этой строки нет или IP адрес указан не верный, необходимо это исправить. Вот пример правильной настройки:
server {
server_name domain.ru www.domain.ru;
listen 8.8.8.8;
...............
}
После внесения изменений в конфигурационный файл Nginx, для вступления в силу этих изменений, нужно перезапустить веб сервер.
service nginx restart
Если в конфигурационном файле Nginx всё указано верно, а сайт открывается не тот, то смотрите настройки в конфигурационном файле Apache.
Подробнее о всех этих ошибках вы можете прочитать тут. Разберем самые распространенные коды ответа.
Успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения.
Запрошенный документ был окончательно перенесен на новый URL указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Подробнее о настройке 301 редиректа вы можете прочитать тут.
Сервер возвращает такой код, если клиент запросил документ методом GET. При этом сообщение сервера не должно содержать тела. Таким способом можно проверить, что кэшируется на вашем сайте, а что нет. Чтобы её убрать нужно смотреть конфигурации кэширующих устройств, это может быть Nginx, eAccelerator, PhpExpress, XCache, Windows Cache Extension for PHP, Zend OPcache, MemCached или Apc.
Сервер обнаружил в запросе клиента синтаксическую ошибку. Причиной могут быть следующие проблемы:
Это самая распространённая причина этой ошибки, в интернете описано много способов удаления куки и кэша на разных брауэрах.
Временно отключив его можно убедиться, что проблема именно в брандмауэре. Для отключения необходимо зайти в Пуск — Панель управления — Система и безопасность — Брандмауэр Windows -Включение и отключение, после чего почистить куки и проверить работу сайтов. Если проблема была в нём, то добавьте в брандмауэр разрешенные программы. Это делается через меню Пуск — Панель управления — Система и безопасность — Брандмауэр — Разрешение запуска программы через брандмауэр. Если ваш браузер не включен в список по умолчанию, внесите его вручную. Потом включите брандмауэр и проверьте, как грузятся страницы.
Чтобы исключить антивирус из списка возможных причин, нужно на время его полностью отключить, перегрузить компьютер и проверить загрузку проблемных страниц при отключенном антивирусе. Если ошибка 400 исчезает, необходимо откорректировать настройки антивирусной программы или сменить антивирусную программу.
Если ничего из выше описанного не помогло, то необходимо проверить работу модема или самого интернет провайдера. Если ошибка всё же иногда появляется, попробуйте сменить вашего интернет провайдера.
Сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента к указанному ресурсу. Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ 401 или 407 при использовании прокси. В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого программного обеспечения.
Наиболее вероятными причинами ограничения может послужить попытка доступа к системным ресурсам веб-сервера (например, файлам .htaccess или .htpasswd) или к файлам, доступ к которым был закрыт с помощью конфигурационных файлов, требование аутентификации не средствами HTTP, например, для доступа к системе управления содержимым или разделу для зарегистрированных пользователей, либо сервер не удовлетворён IP-адресом клиента, например, при блокировках, также причиной может быть не правильно выставленные права на файлы. Подробности о причинах блокировки файла, вы можете увидеть в логах сайта или в логах вашей CMS, также вы можете в файл .htaccess, что лежит в корне вашего сайта прописать:
php_flag display_errors on
Тогда ошибки будут выводиться не только в логи, но и на экран при открытии сайта.
Самая распространенная ошибка при пользовании Интернетом, основная причина — ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URL. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410. Ответ 404 может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы. Подробности о том, какой файл не получается открыть по ссылке, вы можете увидеть в логах сайта или в логах вашей CMS, также вы можете в файл .htaccess, что лежит в корне вашего сайта прописать:
php_flag display_errors on
Тогда ошибки будут выводиться не только в логи, но и на экран при открытии сайта.
Возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса (длина URL). Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса. Возникает часто при загрузки больших файлов. Для решения проблемы, если у вас стоит Nginx нужно в конфиге добавить или увеличить параметр
client_max_body_size 100m;
Если у вас стоит Apache, то нужно в конфиге PHP, файл php.ini, увеличить параметры:
post_max_size = 100m upload_max_filesize = 100m
Любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса. Часто эту ошибку заменяют просто белой страницей. Подробнее о причинах этой ошибки вы можете увидеть в логах сайта или в логах вашей CMS, также вы можете в файл .htaccess, что лежит в корне вашего сайта прописать:
php_flag display_errors on
Тогда ошибки будут выводиться не только в логи, но и на экран при открытии сайта.
Сервер, выступая в роли шлюза или прокси-сервера, получил недействительное ответное сообщение от вышестоящего сервера. В данном случае Nginx работает как Front-end и проксируя запрос ему никто не ответил. В качестве Back-end могут выступать Apache, php-fpm или node.js, вот именно они в данном случае не работают. Вам надо их запустить.
Чтобы узнать причину их отключения вам нужно посмотреть в логи ошибок установленного Web-сервера.
Ошибка может появится из следующих проблем:
Сервер в роли шлюза или прокси-сервера не дождался ответа от вышестоящего сервера для завершения текущего запроса. Причины:
proxy_read_timeout 120; proxy_connect_timeout 120;
Обращаю ваше внимание, увеличение этого параметра может увеличить нагрузку на ваш сервер.
Советую посмотреть инструкцию по уменьшению нагрузки на сервер
случае неоднократного повторения проблемы и/или перезагрузка сервера не помогает в ее решении необходимо написать запрос в техническую поддержку.
Если нужно узнать причины недоступности сервера и устранить их, чтобы подобные проблемы не повторялись в будущем, и у вас есть пакет поддержки, советую вам, не перезагружая сервер, написать запрос в техническую поддержку.
