Веб-серверы Nginx и Apache мало похожи друг на друга, и их отличия касаются не только особенностей подключения пользователей, но и обработки URL на сервере. Очень часто новые пользователи Nginx получают ошибку 404 для URL, которые, по сути, должны были бы работать.
В этой статье рассмотрим, почему возникает ошибка «404 not found Nginx», а также способы её устранения и отладки.Мы не будем разбираться с ситуацией, когда файла действительно нет на сервере — это решение, не требующее пояснений. Мы рассмотрим проблему обработки location в Nginx.
Давайте сначала разберёмся, как обрабатываются URL в Nginx. Когда веб-сервер определил, к какому блоку server (сайту) нужно передать запрос пользователя, просматриваются все префиксные блоки location и выбирается тот, который подходит лучше всего. Например, рассмотрим стандартную конфигурацию для WordPress. Здесь префиксные location отмечены зелёным, а с регулярным выражением — оранжевым:
location / {
index index.html index.php;
}
location /favicon.ico {
access_log off;
}
location ~* .(gif|jpg|png)$ {
expires 30d;
}
location ~ .php$ {
fastcgi_pass localhost:9000;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
include fastcgi_params;
}
Префиксные локейшены всегда начинаются с символа /. Регулярные же содержат символы регулярных выражений: ~ $ ^ * и так далее. Если пользователь запрашивает favicon.ico, то будет выбран второй location, так как он лучше всего соответствует запросу, при любом другом запросе будет выбран location /, так как он соответствует всем запросам, а других префиксных location у нас нет. Это просто, а дальше начинается магия. После того, как был найден нужный location, Nginx начинает проверять все регулярные выражения в порядке их следования в конфигурационном файле.
При первом же совпадении Nginx останавливает поиск и передаёт управление этому location. Или, если совпадений не было найдено, используется ранее обнаруженный префиксный location. Например, если запрос заканчивается на .php, то первый location будет проигнорирован, а управление передастся четвёртому (~ .php$)
Таким образом, любое неверно составленное регулярное выражение в любой части конфигурационного файла может полностью всё сломать. Поэтому разработчики рекомендуют по минимум использовать регулярные выражения. Что касается вложенных location, то обрабатываются они так же как и основные, только уже после передачи управления в нужный location. Путём чтения конфигурационного файла понять, какой location вызывает 404 сложно, поэтому, чтобы исправить ошибку, нам понадобиться режим отладки Nginx.
Как включить режим отладки Nginx?
Сначала нам необходимо установить версию Nginx с поддержкой отладки. Чтобы проверить, поддерживает ли ваша текущая версия этот режим, наберите:
nginx -V
В выводе должна быть строчка «—with-debug». Если её нет, значит отладка не поддерживается, и надо установить версию с поддержкой. В CentOS такой пакет называется nginx-debug. Для его установки наберите:
sudo yum install nginx-debug
Теперь появился ещё один исполняемый файл, и он собран уже с поддержкой отладки:
nginx-debug -V
Откройте конфигурационный файл вашего сайта или глобальный конфигурационный файл, если вы не задавали настройки логов отдельно для каждого сайта, и в конце стоки error_log замените error на debug:
error_log /var/log/nginx/domains/test.losst.pro.error.log debug
Останавливаем обычную версию и запускаем версию с отладкой:
systemctl stop nginx
systemctl start nginx-debug
Как исправить «404 Not Found Nginx»?
1. Регулярные выражения
Как я уже сказал выше, самой частой проблемой, которая вызывает 404, являются регулярные выражения. Смотрим, что происходит в лог файле:
tail -f /var/log/nginx/domains/test.losst.pro.error.log
Видим, что серверу пришёл запрос /vstats. Дальше он проверяет location: /, /robots.txt, /vatsts/, /site-control/. Здесь уже можем понять, в чём проблема — промазали на один слеш. Дальше проверяются все регулярные выражения, и, так как в них ничего найдено не было, выбирается location /.
Далее директива try_files пытается найти файл /vstats, не находит и ищет index.php, который, в свою очередь, возвращает 404.
Если мы наберём, то что ожидает видеть Nginx — /vstats/, то откроется наша страница статистики.
Если мы добавим к конфигурационному файлу ещё один location с регулярным выражением, например:
location ~* {
try_files $uri $uri/ =404;
}
То абсолютно все запросы будут обрабатываться именно этим регулярным выражением и, естественно, что ничего работать не будет. Видим, что приходит запрос /vstats/:
Он совпадает с префиксным location, но потом Nginx видит наше регулярное выражение и передаёт управление ему.
Поэтому будьте очень осторожны с регулярными выражениями, если они вам нужны, то размещайте их только внутри префиксных location, чтобы ограничить их область действия этим location, иначе может возникнуть ошибка 404 nginx.
2. Недостаточно памяти
Если php-скрипту не хватило оперативной памяти для выполнения, и его процесс был убит операционной системой, то Nginx тоже может вернуть ошибку 404. Такое поведение вы будете наблюдать, когда скрипт очень долго выполняется, а потом появляется «404 Not Found» или страница ошибки вашего движка. Обычно эта неисправность тоже видна в отладочном логе.
Решить такую проблему можно, освободив память на сервере, часто такое может возникать из-за утечек памяти в php, когда процессы php-fpm занимают почти всю память на сервере. Поэтому перезапуск php-fpm решает проблему:
systemctl restart php-fpm
Чтобы избежать этой проблемы в будущем, можно настроить автоматический перезапуск процессов после обработки определённого количества запросов. Например каждые 200 запросов:
vi /etc/php-fpm.d/www.conf
pm.max_requests = 200
3. Не найден index
Если вы запрашиваете URL вида /vstats/, но в настройках Nginx не указан файл index, который нужно использовать для этой ссылки, то у вас ничего не выйдет, и вы получите 404. Вы можете добавить директиву index в ваш location:
location / {
index index.php index.html index.htm;
}
Или сразу в server, в Nginx все location наследуют директивы, установленные в server.
4. Другие проблемы
Подобных проблем, вызывающих 404 в Nginx, может быть очень много, но все они решаемы, и всё, что нужно для их решения, есть в отладочном логе Nginx. Просто анализируйте лог и на основе этого вносите исправления.
Выводы
В этой статье мы рассмотрели основные причины, из-за которых может возникнуть ошибка 404 not found Nginx. Как видите, может быть много проблем, но всё достаточно просто решается. А с какими проблемами, вызывающими эту ошибку, вы сталкивались? Как их решали? Напишите в комментариях!
Обнаружили ошибку в тексте? Сообщите мне об этом. Выделите текст с ошибкой и нажмите Ctrl+Enter.
Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна .
Nginx – очень популярный веб-сервер в наши дни.
В этой статье мы расскажем вам о некоторых распространенных ошибках при работе веб-сервера Nginx и возможных решениях.
Это не полный список.
Если вы все еще не можете устранить ошибку, попробовав предложенные решения, пожалуйста, проверьте логи сервера Nginx в каталоге /var/log/nginx/ и поищите в Google, чтобы отладить проблему.
Содержание
- Unable to connect/Refused to Connect
- The Connection Has Timed Out
- 404 Not Found
- 403 Forbidden
- 500 Internal Server Error
- Nginx показывает страницу по умолчанию
- 504 Gateway time-out
- Размер памяти исчерпан
- PR_END_OF_FILE_ERROR
- Resource temporarily unavailable
- Два файла виртуального хоста для одного и того же сайта
- PHP-FPM Connection reset by peer
- Утечки сокетов Nginx
- Заключение
Unable to connect/Refused to Connect
Если при попытке получить доступ к вашему сайту вы видите следующую ошибку:
Firefox can’t establish a connection to the server at www.example.com
или
www.example.com refused to connect
или
The site can't be reached, www.example.com unexpectedly closed the connection.
Это может быть потому, что:
- Nginx не запущен. Вы можете проверить состояние Nginx с помощью sudo systemctl status nginx. Запустите Nginx с помощью sudo systemctl start nginx. Если Nginx не удается запустить, запустите sudo nginx -t, чтобы выяснить, нет ли ошибок в вашем конфигурационном файле. И проверьте логи (sudo journalctl -eu nginx), чтобы выяснить, почему он не запускается.
- Брандмауэр блокирует порты 80 и 443. Если вы используете брандмауэр UFW на Debian/Ubuntu, выполните sudo ufw allow 80,443/tcp, чтобы открыть TCP порты 80 и 443. Если вы используете Firewalld на RHEL/CentOS/Rocky Linux/AlmaLinux, выполните sudo firewall-cmd –permanent –add-service={http,https}, затем sudo systemctl reload firewalld, чтобы открыть TCP порты 80 и 443.
- Fail2ban. Если ваш сервер использует fail2ban для блокировки вредоносных запросов, возможно, fail2ban запретил ваш IP-адрес. Выполните команду sudo journalctl -eu fail2ban, чтобы проверить, не заблокирован ли ваш IP-адрес. Вы можете добавить свой IP-адрес в список fail2ban ignoreip, чтобы он больше не был забанен.
- Nginx не прослушивает нужный сетевой интерфейс. Например, Nginx не прослушивает публичный IP-адрес сервера.
The Connection Has Timed Out
Это может означать, что ваш сервер находится в автономном режиме или Nginx работает неправильно.
Однажды у меня возникла проблема нехватки памяти, из-за чего Nginx не смог запустить рабочие процессы.
Если вы увидите следующее сообщение об ошибке в файле /var/log/nginx/error.log, вашему серверу не хватает памяти:
fork() failed while spawning "worker process" (12: Cannot allocate memory)
404 Not Found
404 not found означает, что Nginx не может найти ресурсы, которые запрашивает ваш веб-браузер.
🌐 Как создать пользовательскую страницу ошибки 404 в NGINX
Причина может быть следующей:
- Корневой каталог web не существует на вашем сервере. В Nginx корневой веб-каталог настраивается с помощью директивы root, например, так: root /usr/share/nginx/linuxbabe.com/;. Убедитесь, что файлы вашего сайта (HTML, CSS, JavaScript, PHP) хранятся в правильном каталоге.
- PHP-FPM не запущен. Вы можете проверить статус PHP-FPM с помощью sudo systemctl status php7.4-fpm (Debian/Ubuntu) или sudo systemctl status php-fpm.
- Вы забыли включить директиву try_files $uri /index.php$is_args$args; в конфигурационный файл сервера Nginx. Эта директива необходима для обработки PHP-кода.
- На вашем сервере нет свободного дискового пространства. Попробуйте освободить немного дискового пространства. Вы можете использовать утилиту ncdu (sudo apt install ncdu или sudo dnf install ncdu), чтобы узнать, какие каталоги занимают огромное количество дискового пространства.
403 Forbidden
Эта ошибка означает, что вам не разрешен доступ к ресурсам запроса.
Возможный сценарий включает:
- Администратор сайта блокирует публичный доступ к запрашиваемым ресурсам с помощью белого списка IP-адресов или других методов.
- На сайте может использоваться брандмауэр веб-приложения, например ModSecurity, который обнаружил атаку вторжения, поэтому заблокировал запрос.
Некоторые веб-приложения могут показывать другое сообщение об ошибке, когда происходит запрет 403. Оно может сказать вам, что “secure connection failed, хотя причина та же.
500 Internal Server Error
Это означает, что в веб-приложении произошла какая-то ошибка.
Это может быть следующее
- Сервер базы данных не работает. Проверьте состояние MySQL/MariaDB с помощью sudo systemctl status mysql. Запустите его с помощью sudo systemctl start mysql. Запустите sudo journalctl -eu mysql, чтобы выяснить, почему он не запускается. Процесс MySQL/MariaDB может быть завершен из-за проблем с нехваткой памяти.
- Вы не настроили Nginx на использование PHP-FPM, поэтому Nginx не знает, как выполнять PHP-код.
- Если ваше веб-приложение имеет встроенный кэш, вы можете попробовать очистить кэш приложения, чтобы исправить эту ошибку.
- Ваше веб-приложение может создавать свой собственный журнал ошибок. Проверьте этот файл журнала, чтобы отладить эту ошибку.
- Возможно, в вашем веб-приложении есть режим отладки. Включите его, и вы увидите более подробные сообщения об ошибках на веб-странице. Например, вы можете включить режим отладки в почтовом сервере хостинг-платформы Modoboa, установив DEBUG = True в файле /srv/modoboa/instance/instance/settings.py.
- PHP-FPM может быть перегружен. Проверьте журнал PHP-FPM (например, /var/log/php7.4-fpm.log). Если вы обнаружили предупреждение [pool www] seems busy (возможно, вам нужно увеличить pm.start_servers, или pm.min/max_spare_servers), вам нужно выделить больше ресурсов для PHP-FPM.
- Иногда перезагрузка PHP-FPM (sudo systemctl reload php7.4-fpm) может исправить ошибку.
Nginx показывает страницу по умолчанию
Если вы пытаетесь настроить виртуальный хост Nginx и при вводе доменного имени в веб-браузере отображается страница Nginx по умолчанию, это может быть следующее
- Вы не использовали реальное доменное имя для директивы server_name в виртуальном хосте Nginx.
- Вы забыли перезагрузить Nginx.
504 Gateway time-out
Это означает, что апстрим, такой как PHP-FPM/MySQL/MariaDB, не может обработать запрос достаточно быстро.
Вы можете попробовать перезапустить PHP-FPM, чтобы временно исправить ошибку, но лучше начать настраивать PHP-FPM/MySQL/MariaDB для более быстрой работы.
Вот конфигурация InnoDB в моем файле /etc/mysql/mariadb.conf.d/50-server.cnf.
Это очень простая настройка производительности.
innodb_buffer_pool_size = 1024M innodb_buffer_pool_dump_at_shutdown = ON innodb_buffer_pool_load_at_startup = ON innodb_log_file_size = 512M innodb_log_buffer_size = 8M #Improving disk I/O performance innodb_file_per_table = 1 innodb_open_files = 400 innodb_io_capacity = 400 innodb_flush_method = O_DIRECT innodb_read_io_threads = 64 innodb_write_io_threads = 64 innodb_buffer_pool_instances = 3
Где:
- InnoDB buffer pool size должен быть не менее половины вашей оперативной памяти. (Для VPS с небольшим объемом оперативной памяти я рекомендую установить размер буферного пула на меньшее значение, например 400M, иначе ваш VPS будет работать без оперативной памяти).
- InnoDB log file size должен составлять 25% от размера буферного пула.
- Установите потоки ввода-вывода для чтения и записи на максимум (64).
- Заставьте MariaDB использовать 3 экземпляра буферного пула InnoDB. Количество экземпляров должно соответствовать количеству ядер процессора в вашей системе.
- После сохранения изменений перезапустите MariaDB.
После сохранения изменений перезапустите MariaDB.
sudo systemctl restart mariadb
Вы также можете установить более длительное значение тайм-аута в Nginx, чтобы уменьшить вероятность тайм-аута шлюза.
Отредактируйте файл виртуального хоста Nginx и добавьте следующие строки в блок server {…}.
proxy_connect_timeout 600; proxy_send_timeout 600; proxy_read_timeout 600; send_timeout 600;
Если вы используете Nginx с PHP-FPM, то установите для параметра fastcgi_read_timeout большее значение, например 300 секунд.
По умолчанию это 60 секунд.
location ~ .php$ {
try_files $uri /index.php$is_args$args;
include snippets/fastcgi-php.conf;
fastcgi_split_path_info ^(.+.php)(/.+)$;
fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
fastcgi_read_timeout 300;
}
Затем перезагрузите Nginx.
sudo systemctl reload nginx
PHP-FPM также имеет максимальное время выполнения для каждого скрипта.
Отредактируйте файл php.ini.
sudo nano /etc/php/7.4/fpm/php.ini
Вы можете увеличить это значение до 300 секунд.
max_execution_time = 300
Затем перезапустите PHP-FPM
sudo systemctl restart php7.4-fpm
Размер памяти исчерпан
Если вы видите следующую строку в журнале ошибок Nginx, это означает, что PHP достиг лимита памяти в 128 МБ.
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 57134520 bytes)
Вы можете отредактировать файл php.ini (/etc/php/7.4/fpm/php.ini) и увеличить лимит памяти PHP.
memory_limit = 512M
Затем перезапустите PHP7.4-FPM.
sudo systemctl restart php7.4-fpm
Если ошибка все еще существует, скорее всего, в вашем веб-приложении плохой PHP-код, который потребляет много оперативной памяти.
PR_END_OF_FILE_ERROR
- Вы настроили Nginx на перенаправление HTTP-запросов на HTTPS, но в Nginx нет блока сервера, обслуживающего HTTPS-запросы.
- Может быть, Nginx не запущен?
- Иногда основной бинарник Nginx запущен, но рабочий процесс может не работать и завершиться по разным причинам. Для отладки проверьте логи ошибок Nginx (/var/log/nginx/error.log).
Resource temporarily unavailable
Некоторые пользователи могут найти следующую ошибку в файле логов ошибок Nginx (в разделе /var/log/nginx/).
connect() to unix:/run/php/php7.4-fpm.sock failed (11: Resource temporarily unavailable)
Обычно это означает, что на вашем сайте много посетителей и PHP-FPM не справляется с обработкой огромного количества запросов.
Вы можете изменить количество дочерних процессов PHP-FPM, чтобы он мог обрабатывать больше запросов.
Отредактируйте файл PHP-FPM www.conf.
(Путь к файлу зависит от дистрибутива Linux).
sudo /etc/php/7.4/fpm/pool.d/www.conf
По умолчанию конфигурация дочернего процесса выглядит следующим образом:
pm = dynamic pm.max_children = 5 pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 3
Приведенная выше конфигурация означает.
- PHP-FPM динамически создает дочерние процессы. Нет фиксированного количества дочерних процессов.
- Создается не более 5 дочерних процессов.
- При запуске PHP-FPM запускаются 2 дочерних процесса.
- Есть как минимум 1 незанятый процесс.
- Максимум 3 неработающих процесса.
pm = dynamic pm.max_children = 20 pm.start_servers = 8 pm.min_spare_servers = 4 pm.max_spare_servers = 12
Убедитесь, что у вас достаточно оперативной памяти для запуска дополнительных дочерних процессов.
Сохраните и закройте файл.
Затем перезапустите PHP-FPM. (Возможно, вам потребуется изменить номер версии).
sudo systemctl restart php7.4-fpm
Чтобы следить за состоянием PHP-FPM, вы можете включить страницу status .
Найдите следующую строку в файле PHP-FPM www.conf.
Обратите внимание, что
;pm.status_path = /status
Уберите точку с запятой, чтобы включить страницу состояния PHP-FPM.
Затем перезапустите PHP-FPM.
sudo systemctl restart php7.4-fpm
Затем отредактируйте файл виртуального хоста Nginx.
Добавьте следующие строки.
Директивы allow и deny используются для ограничения доступа.
Только IP-адреса из “белого списка” могут получить доступ к странице состояния.
location ~ ^/(status|ping)$ {
allow 127.0.0.1;
allow your_other_IP_Address;
deny all;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_index index.php;
include fastcgi_params;
#fastcgi_pass 127.0.0.1:9000;
fastcgi_pass unix:/run/php/php7.4-fpm.sock;
}
Сохраните и закройте файл. Затем протестируйте конфигурацию Nginx.
sudo nginx -t
Если проверка прошла успешно, перезагрузите Nginx, чтобы изменения вступили в силу.
sudo systemctl reload nginx
В файле PHP-FPM www.conf дается хорошее объяснение того, что означает каждый параметр.
Если PHP-FPM очень занят и не может обслужить запрос немедленно, он поставит его в очередь.
По умолчанию может быть не более 511 ожидающих запросов, определяемых параметром listen.backlog.
listen.backlog = 511
Если вы видите следующее значение на странице состояния PHP-FPM, это означает, что в очереди еще не было ни одного запроса, т.е. ваш PHP-FPM может быстро обрабатывать запросы.
listen queue: 0 max listen queue: 0
Если в очереди 511 ожидающих запросов, это означает, что ваш PHP-FPM очень загружен, поэтому вам следует увеличить количество дочерних процессов.
Вам также может понадобиться изменить параметр ядра Linux net.core.somaxconn, который определяет максимальное количество соединений, разрешенных к файлу сокетов в Linux, например, к файлу сокетов PHP-FPM Unix.
По умолчанию его значение равно 128 до ядра 5.4 и 4096 начиная с ядра 5.4.
$ sysctl net.core.somaxconn net.core.somaxconn = 128
Если у вас сайт с высокой посещаемостью, вы можете использовать большое значение.
Отредактируйте файл /etc/sysctl.conf.
sudo nano /etc/sysctl.cnf
Добавьте следующие две строки.
net.core.somaxconn = 20000 net.core.netdev_max_backlog = 65535
Сохраните и закройте файл. Затем примените настройки.
sudo sysctl -p
Примечание: Если ваш сервер имеет достаточно оперативной памяти, вы можете выделить фиксированное количество дочерних процессов для PHP-FPM, как показано ниже.
Два файла виртуального хоста для одного и того же сайта
Если вы запустите sudo nginx -t и увидите следующее предупреждение.
nginx: [warn] conflicting server name "example.com" on [::]:443, ignored nginx: [warn] conflicting server name "example.com" on 0.0.0.0:443, ignored
Это означает, что есть два файла виртуальных хостов, содержащих одну и ту же конфигурацию server_name.
Не создавайте два файла виртуальных хостов для одного сайта.
PHP-FPM Connection reset by peer
В файле логов ошибок Nginx отображается следующее сообщение.
recv() failed (104: Connection reset by peer) while reading response header from upstream
Это может быть вызвано перезапуском PHP-FPM.
Если он перезапущен вручную самостоятельно, то вы можете игнорировать эту ошибку.
Утечки сокетов Nginx
Если вы обнаружили следующее сообщение об ошибке в файле /var/log/nginx/error.log, значит, у вашего Nginx проблема с утечкой сокетов.
2021/09/28 13:27:41 [alert] 321#321: *120606 open socket #16 left in connection 163 2021/09/28 13:27:41 [alert] 321#321: *120629 open socket #34 left in connection 188 2021/09/28 13:27:41 [alert] 321#321: *120622 open socket #9 left in connection 213 2021/09/28 13:27:41 [alert] 321#321: *120628 open socket #25 left in connection 217 2021/09/28 13:27:41 [alert] 321#321: *120605 open socket #15 left in connection 244 2021/09/28 13:27:41 [alert] 321#321: *120614 open socket #41 left in connection 245 2021/09/28 13:27:41 [alert] 321#321: *120631 open socket #24 left in connection 255 2021/09/28 13:27:41 [alert] 321#321: *120616 open socket #23 left in connection 258 2021/09/28 13:27:41 [alert] 321#321: *120615 open socket #42 left in connection 269 2021/09/28 13:27:41 [alert] 321#321: aborting
Вы можете перезапустить ОС, чтобы решить эту проблему.
Если это не помогает, вам нужно скомпилировать отладочную версию Nginx, которая покажет вам отладочную информацию в логах.
Заключение
Надеюсь, эта статья помогла вам исправить распространенные ошибки веб-сервера Nginx.
см. также:
- 🌐 Как контролировать доступ на основе IP-адреса клиента в NGINX
- 🐉 Настройка http-сервера Kali Linux
- 🌐 Как парсить логи доступа nginx
- 🌐 Ограничение скорости определенных URL-адресов с Nginx
- 🛡️ Как использовать обратный прокси Nginx для ограничения внешних вызовов внутри веб-браузера
- 🔏 Как настроить Nginx с Let’s Encrypt с помощью ACME на Ubuntu
- 🌐 Как собрать NGINX с ModSecurity на Ubuntu сервере
Here are my nginx configure files.
On the default.conf, the first location is used to access /usr/share/nginx/html directory, it is ok while I access http://47.91.152.99.
But when I add up a new location for directory /usr/share/nginx/public directory, nginx return me a 404 page while I access http://47.91.152.99/test.
So, what is the matter? Am I misuse the directive of nginx?
/etc/nginx/nginx.conf
user nginx;
worker_processes 1;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
include /etc/nginx/conf.d/*.conf;
}
/etc/nginx/conf.d/default.conf
server {
listen 80;
server_name localhost;
#charset koi8-r;
#access_log /var/log/nginx/log/host.access.log main;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
location ^~ /test/ {
root /usr/share/nginx/public;
index index.html index.htm;
}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
}
asked Dec 12, 2016 at 10:58
3
The following erroneous block (in your case);
location ^~ /test/ {
root /usr/share/nginx/public;
index index.html index.htm;
}
is telling nginx to look for directory ‘test’ into the folder (root) /usr/share/nginx/public. If there’s no ‘test’ folder in that root, it will return 404. To paliate to your problem, i suggest you try using alias instead of root. Like so:
location ^~ /test/ {
alias /usr/share/nginx/public;
index index.html index.htm;
}
Also, just for kicks, index directive can be set generally so you don’t have to re-write it all the time… like so;
server {
listen 80;
server_name localhost;
root /usr/share/nginx/html;
index index.html index.htm;
error_page 500 502 503 504 /50x.html;
location / { }
location ~^/test/ {
alias /usr/share/nginx/public;
}
location = /50x.html {
root /usr/share/nginx/html;
}
}
One thing you should also consider… the more ‘precise’ the location block, the higher in your config it should reside. Like that location = /50x.html. In a perfect world, that would be set up top, right after the general server block settings.
Hope it helps.
answered Dec 12, 2016 at 12:59
OldFartOldFart
1,58010 silver badges20 bronze badges
4
Error caused by root directive
location ^~ /test/ {
root /usr/share/nginx/public;
index index.html index.htm;
}
Fix with alias directive
location ^~ /test/ {
alias /usr/share/nginx/public;
index index.html index.htm;
}
Other Improvements
Extra tip: the index directive can be set so that you don’t have to re-write it.
server {
listen 80;
server_name localhost;
root /usr/share/nginx/html;
index index.html index.htm;
error_page 500 502 503 504 /50x.html;
location / { }
location ~^/test/ {
alias /usr/share/nginx/public;
}
location = /50x.html {
root /usr/share/nginx/html;
}
}
nginx matches Location blocks partly based on position in the config. Ideally, you would invert what you have now. The location block would be higher in nginx config. To that end, the location = /50x.html would also move up. Order is
- Exact match =
- Forward match ^~ /
- Case sensitive regex ~ /
- Case insensitive regex ~*
- Path match /
More about nginx location priority. Also, you can always review the official documentation. The nginx documentation for location block http://nginx.org/en/docs/http/ngx_http_core_module.html#location
answered Nov 11, 2018 at 9:11
gtzillagtzilla
1,2451 gold badge16 silver badges21 bronze badges
1
when your app is vuejs，you need write like this,can prevent 404,pay attention to double /test/
location ^~/test/ {
alias /usr/local/soft/vuejs/;
try_files $uri $uri/ /test/index.html;
}
answered Jun 22, 2020 at 13:36
yongfa365yongfa365
3423 silver badges7 bronze badges
1
I just solved this (index.html not found) issue.
For me, I misstyped my project name to match your ec2 project name with the nginx path.
Move to nginx/sites-enabled to check nginx path
- cd /etc/nginx/sites-enabled
catyour_project_name- Check your nginx path
(for me : root/home/ubuntu/practice/current/public;)
Move to home directory to check your project name
4. cd
5. ls
6. If your ec2 project name(for me: practice) is not match with your nginx path name(for me: practice) then you might got «index.html not found error»
ouflak
2,44810 gold badges44 silver badges49 bronze badges
answered Oct 10, 2021 at 9:02
2
and my server-blocks.conf
server {
listen 80;
index index.html index.htm index.nginx-debian.html;
server_name 13.xxx.xxx.xx;
location / {
root /var/www/portaladmin/;
proxy_pass http://13.xxx.xxx.xx:80/;
}
error_log /var/log/nginx/portaladmin-erorr.log;
}
and my load-balancer.conf
server {
listen 80;
server_name xx.xxx.xxx.xx
access_log /home/ec2-user/logs/lb-access.log;
error_log /home/ec2-user/logs/lb-error.log;
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://13.xxx.xxx.xx:80;
}
}
answered Oct 12, 2021 at 4:23
1
Creating nginx & sftp pods using Kubernetes.. I’ve found that the mountPath in my sftp-deployment.yaml file is related to the username in my sftp-server.
And the error has happened when I have changed the username without changing mountPath value to match my username. So, the files were uploading to ‘/home/old-username’ instead of ‘/home/new-username’.
answered Aug 11, 2022 at 18:12
На чтение 4 мин Просмотров 9.3к. Опубликовано 14.10.2021
Когда вы посещаете веб-сайт, настроенный для Nginx, ваш браузер отправляет запрос на веб-сервер. После этого ваш веб-сервер отвечает данными, имеющими заголовок HTTP. Коды состояния HTTP включены в этот HTTP-заголовок, чтобы объяснить, как выполняется ответ на запрос.
Когда ваши запросы обрабатываются успешно, код состояния HTTP не отображается в вашем браузере. Однако, если что-то пойдет не так, ваш веб-браузер обычно отображает сообщение с кодом состояния HTTP, чтобы сообщить вам о проблеме с запросом. Сообщения об ошибках, такие как 504, 500, 503, 502, включая сообщение » Ошибка 404 не найдена «, являются частью этого процесса.
Содержание
- Что означает ошибка 404 в Nginx
- Как исправить ошибку 404 в Nginx
- Как исправить ошибку 404 Nginx с помощью онлайн-инструментов
- W3C Проверить ссылку
- Check My Links
- Broken Link Checker
- Заключение
Что означает ошибка 404 в Nginx
По сути, » ошибка 404 ″ означает, что ваш веб-браузер или веб-браузер вашего посетителя был успешно подключен к серверу веб-сайта или хосту. Однако ему не удалось найти запрошенный ресурс, например имя файла или какой-либо конкретный URL-адрес.
Например, если кто-то попытается перейти на » yourwebsite.com/anypostname » и не имеет никакого контента, связанного с » anypostname «, в таком случае вы получите ошибку 404 в своем браузере, поскольку запрошенный ресурс не существует. Другими словами, мы можем сказать, что когда запрашиваемый ресурс, такой как файл JavaScript, изображение или CSS, отсутствует, ваш работающий браузер выдаст ошибку „404“.
Как исправить ошибку 404 в Nginx
Если вы получаете сообщение об ошибке Nginx » 404 Not Found » и проверили, что запрошенный актив существует на вашем сервере, то ваш файл конфигурации может вызывать ошибку. Чтобы исправить ошибку » 404 Not Found «, откройте свой терминал, нажав » CTRL + ALT + T «, и выполните приведенную ниже команду для открытия файла конфигурации Nginx:
$ sudo nano /etc/nginx/nginx.conf
Ваш файл конфигурации Nginx будет выглядеть так:
Если путь, добавленный в файл конфигурации Nginx, неверен, это приведет к ошибке Ngnix » 404 Not Found «. Итак, проверьте свой путь, ведущий к каталогу активов:
root /usr/share/nginx/html;
Также будет полезно просмотреть ваши ошибки и получить доступ к журналам в Nginx. Для этого используйте приведенную ниже команду » cat » для извлечения содержимого error_log, присутствующего в файле » /var/log/nginx/error.log «:
$ sudo cat /var/log/nginx/error.log
Чтобы проверить содержимое access_log, запишите эту команду в своем терминале:
$ sudo cat /var/log/nginx/access.log
Как исправить ошибку 404 Nginx с помощью онлайн-инструментов
» Ошибка 404 Nginx » также связана с внешними ресурсами и возникает, когда эти ресурсы удаляются или изменяются. Вот почему так важно часто выполнять проверку ошибок 404, чтобы убедиться, что ссылки на ваш веб-сайт не повреждены. Регулярная проверка и исправление неработающих ссылок поможет вам убедиться, что пользовательский опыт посетителя вашего веб-сайта находится на стабильном уровне. Ниже приведены некоторые инструменты, которые можно использовать для проверки ошибок «404 Not Found»:
W3C Проверить ссылку
В онлайн-инструменте W3C Link Checker вы должны ввести URL-адрес своего веб-сайта, и он просканирует все ваши веб-страницы на предмет 404 Not Found и других проблем. Когда сканирование закончится, оно вернет все неработающие URL-адреса вместе с другими результатами:
Check My Links
Check My Links — это базовый плагин Chrome, который позволяет вам проверять ссылки на текущей веб-странице. Когда этот плагин активирован, расширение определит, действительны ли ссылки на текущей странице или нет:
Broken Link Checker
Broken Link Checker — еще один полезный плагин, который предлагает различные методы проверки неработающих ссылок на вашем сайте. Можно установить период времени, при котором этот плагин будет проверять неработающие ссылки каждые «X» часов. Вы можете выбрать, должен ли плагин отправлять по электронной почте отчет, содержащий все неработающие ссылки или часть сайта, которая успешно просканирована:
Если вы столкнулись с ошибкой Nginx «404 Not Found» или хотите убедиться, что ссылки на ваш сайт не сломаны, или отслеживать ваш сайт, используйте вышеуказанные методы, чтобы исправить это.
Заключение
» Ошибка 404 Not Found » на веб-странице — это код состояния HTTP-ответа, который объявляет, что запрошенный ресурс не найден. Вам может быть сложно выяснить причину » ошибки 404 not found «. В этом посте мы объяснили, что такое «ошибка 404 Not Found». Мы также предоставили вам способы исправить «ошибку 404 Not Found», используя файл конфигурации Nginx и другие онлайн-инструменты, такие как «Проверить мои ссылки», «Проверить ссылку W3C» и «Проверка неработающих ссылок».
There are many times when you have installed NGINX but sometimes you will come across the weird thing ie 404 not found.
In thing article I will walk you through how to get it resolved.
Prerequisites
You have NGINX installed. If not then in Ubuntu or any Debain version you can install with the following
sudo apt-get update sudo apt-get install nginx
1) Forgot To Restart NGINX Server
Most of the times developer change the configuration file and forget to restart the NGINX server
First TEST if the NGINX configuration is correct or not with the following command
sudo nginx -t
If everything is correct then run the reload command
sudo service nginx reload
I have written a detailed article on how to install and manage your NGINX server in Linux don’t forget to check it out How To Install NGINX In Linux / Ubuntu Package Manager & Manage It.
2) Created New Configuration File But Not Activated
All your configuration files resides in /etc/nginx/sites-available & once you activate them they will be in /etc/nginx/sites-enabled which are eventually the symbolic link to sites-available.
By default the default configuration file will be enabled first go to sites-enabled folder and remove the soft link of default. Don’t worry you can activate it later.
You might have your website configuration file in sites-available For Eg. Mine is stackcoder.in which wont be activated inside sites-enabled. To activate the configuration file use the following code
sudo ln -s /etc/nginx/sites-available/stackcoder.in /etc/nginx/sites-enabled/
Make sure to change it to your configuration file name.
3) If Using PHP, Then Check If PHP Socket Exists
Go to your website configuration file inside /etc/nginx/sites-available/stackcoder.in , here mine is stackcoder.in your’s might be different. And here you look for the following code block
location ~ .php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/var/run/php/php7.2-fpm.sock; }
Check if this path exists unix:/var/run/php/php7.2-fpm.sock
4) If Using LARAVEL Project
If your using LARAVEL project with NGINX configuration file then make sure to include the following file inside /etc/nginx/sites-available/stackcoder.in make sure to check your configuration file name and make the following changes
location / { try_files $uri $uri/ /index.php?q=$uri&$args; }
NOTE: Don’t forget to restart the NGINX server after doing this
5) FASTCGI_PARAM Issues
Sometimes you might have set the wrong path for fastcgi_param
WRONG Configuration
location ~ .php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/var/run/php/php7.2-fpm.sock; fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name; include fastcgi_params; }
CORRECT Configuration
I prefer the following one
location ~ .php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/var/run/php/php7.2-fpm.sock; fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name; include fastcgi_params; }
OR
location ~ .php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/var/run/php/php7.2-fpm.sock; fastcgi_param SCRIPT_FILENAME /usr/share/nginx/html$fastcgi_script_name; include fastcgi_params; }
6) Project Files / NGINX Permission Issues
Yup you read it right. Some times you will face problems when you might have installed the project in wrong directory, or directory without proper permission privileges issues.
Cross check if the project path and any other path given in NGINX configuration is correct or not.
Check if there are any permission issues. You can find the error logs in /var/log/nginx/error.log
7) Uninstall & Install NGINX Again (Last Brahmastra)
Some times NGINX can be mischievous, He he he! kidding. Just re-installing works
To remove NGINX use the following command
sudo apt-get remove nginx
To install it again use the following command
sudo apt-get install nginx
Conclusion
Hope this article helped you. I have written other articles on NGINX kindly check them too
How To Cache Static Files With NGINX Server
Redirect www to a non-www website or vice versa
How To Create Free SSL Certificate With Lets Encrypt/Certbot In Linux (Single / Multiple Domains)
How To Install Linux, NGINX, MYSQL, PHP (LEMP Stack) on Ubuntu