Диагностика ошибки 400 Bad Request
Ошибка 400 Bad Request означает, что сервер (удалённый компьютер) не может обработать запрос, отправленный клиентом (браузером), вследствие проблемы, которая трактуется сервером как проблема на стороне клиента.
Существует множество сценариев, в которых ошибка 400 Bad Request может появляться в приложении. Ниже представлены некоторые наиболее вероятные случаи:
- Клиент случайно (или намеренно) отправляет информацию, перехватываемую маршрутизатором ложных запросов. Некоторые веб-приложения ищут особые заголовки HTTP, чтобы обрабатывать запросы и удостовериться в том, что клиент не предпринимает ничего зловредного. Если ожидаемый заголовок HTTP не найден или неверен, то ошибка 400 Bad Request – возможный результат.
- Клиент может загружать слишком большой файл. Большинство серверов или приложений имеют лимит на размер загружаемого файла, Это предотвращает засорение канала и других ресурсов сервера. Во многих случаях сервер выдаст ошибку 400 Bad Request, когда файл слишком большой и поэтому запрос не может быть выполнен.
- Клиент запрашивает неверный URL. Если клиент посылает запрос к неверному URL (неверно составленному), это может привести к возникновению ошибки 400 Bad Request.
- Клиент использует недействительные или устаревшие куки. Это возможно, так как локальные куки в браузере являются идентификатором сессии. Если токен конкретной сессии совпадает с токеном запроса от другого клиента, то сервер/приложение может интерпретировать это как злонамеренный акт и выдать код ошибки 400 Bad Request.
Код ошибки 403 – как исправить администратору
Если вы являетесь администратором сайта и не можете открыть какую-либо страницу, это означает все ту же ошибку. Исправить ее можно через панель администрирования. Если вы заходите на собственный сайт и получаете сообщение типа 403 forbidden, попробуйте узнать из файла htaccess что она означает и как ее исправить. Он расположен в корневом каталоге сайта.
Найдя данный файл, нужно выполнить следующие действия:
- попробовать переименовать его;
- взамен поставить новый либо скачанный файл с первоначальным названием;
- открыть страницу, на которой появлялось сообщение об ошибке.
Если это не помогло и монитор снова выдает ошибку 403, то скорее всего у вас ошибка в настройках прав доступа.
Найдите корневой каталог и, нажав на него, щелкните левой клавишей мыши, а затем проведите следующие действия:
выбрав пункт Атрибуты файл, в открывшемся окне в поле Значение введите 755;
- внизу окна выберите пункт Применить только к каталогам.
- подтвердив данное действие, повторите те же манипуляции, введя числовое значение 644 и выбрав пункт Применить только к файлам.
Заключительным этапом является проверка новых настроек. Для этого снова войдите на страницу и выясните, устранена ли проблема.
Если вновь ничего не получилось и появляется ошибка 403, это означает, что она возникает из-за плагинов. Для исправления этой ситуации необходимо изменить имя каталога с плагинами — это отключит их и ошибка будет устранена.
Зная о том, как исправить код ошибки 403, вы можете обеспечить бесперебойную работу вашего сайта
Ошибка 403 Forbidden Nginx
Итак, ошибка 403 forbidden nginx 1.4 6 Ubuntu может возникать в таких случаях:
- Пользователь заблокирован на сервере с помощью директивы deny в конфигурации nginx;
- Доступ к данному ресурсу разрешен только с определенного IP адреса;
- Пользователь пытается получить доступ к папке, отображение содержимого которой запрещено;
- Nginx не может прочитать содержимое запрашиваемого файла в файловой системе;
- Файл index не найден в каталоге.
Это основные причины, которые встречаются наиболее часто. Как видите, две последние из них представляют из себя проблему. Рассмотрим как ее решить.
Неверно выставлены права
Если права на файл, который пытается получить пользователь выставлены неправильно, то будет выдана такая ошибка. Необходимо, чтобы у Nginx были права не только на чтение этого файла, но и на чтение все родительских каталогов. Это можно проверить командой:
Для всех элементов пути должен быть установлен флаг «r», чаще всего лучше подходят права 644, то есть, владелец может все, а группа и остальные только читать. Если права не соответствуют, то вы нашли проблему и осталось только исправить права с помощью chmod. Например:
Вот так должно быть:
Также обратите внимание на владельца файлов и папок. Если nginx должен иметь возможность выполнять туда запись, то, возможно есть смысл сделать владельцем пользователя nginx или позже получите другую ошибку
Также, если с правами все хорошо, но ошибка не решена попробуйте отключить SELinux, возможно, эта служба мешает Nginx получить доступ к файлам.
Если вы используете PHP и получаете такую ошибку, то еще нужно проверить может ли Nginx получить доступ к сокету обработчика PHP. Желательно, чтобы php-fpm запускался с той же группой, что и nginx, потому что права, по умолчанию, для доступа к сокету 660 (для группы и для владельца). Поэтому проверьте поля listen.owner и listen.group в файле /etc/php5/fpm/php-fpm.conf.
Также можно попытаться использовать сетевой сокет и подключаться к порту, а не файлу.
Неверно настроен index
Файл index открывается по умолчанию при запросе папки на сервере, в которой он находится. Если такого файла в папке нет или он настроен неправильно в конфигурационном файле nginx, то программа попытается отобразить содержимое папки, а это по умолчанию запрещено, поэтому вы получите 403 Foribden.
Чтобы решить проблему убедитесь, что файл index.html, index.php или как он у вас называется, находится в нужно папке, в той, которую вы запрашиваете. Проверьте конфигурационный файл и убедитесь, что в нем указана директива Index с правильным именем и расширением файла:
Если в директиве указаны только файлы html, а вы используете php, то уже понятно почему программа не может найти то, что нужно. Просто добавьте имя файла в директиву:
Точно так же, если вы использовали python скрипт, то нужно добавить его расширение.
Причина 5: Неправильные настройки сайта
Если вы – веб-разработчик или администратор, и попытка открыть ваш же ресурс приводит к подобной проблеме, скорее всего, причина в неправильно заданных параметрах сайта. Первым делом убедитесь, что дали заглавной странице корректное название – многие платформы требуют, чтобы она называлась исключительно index. Также ознакомьтесь с документацией платформы, на которой должен хоститься ресурс, — обычно там освещаются подобные нюансы. Также проверьте разграничение прав доступа к данным в среде разработки – возможно, действует запрет на просмотр.
Опишите, что у вас не получилось.
Наши специалисты постараются ответить максимально быстро.
Как решить проблему, если вы – пользователь
Выше я рассмотрела способы устранения ошибки 403 Forbidden для владельцев сайта. Теперь же разберу методы исправления в случаях с пользователем.
- Сначала надо убедиться, что проблема заключается именно в вашем устройстве. Внимательно проверьте, правильно ли вы ввели URL сайта. Может, в нем есть лишние символы. Или, наоборот, какие-то символы отсутствуют.
- Попробуйте загрузить страницу с другого устройства. Если на нем все будет нормально, значит, проблема кроется именно в используемом вами девайсе. Если нет – надо перейти к последнему шагу.
- Еще хороший вариант – немного подождать и обновить страницу. Делается это либо кликом по иконке возле адресной строки браузера, либо нажатием на комбинацию Ctrl + F5. Можно и без Ctrl, на ваше усмотрение.
- Если ничего из вышеперечисленного не помогло, надо очистить кэш и cookies. Провести такую процедуру можно через настройки браузера. Для этого необходимо открыть историю просмотров, чтобы через нее перейти к инструменту очистки. Эту же утилиту часто можно найти в настройках, в разделе «Конфиденциальность и безопасность». В новом окне нужно отметить пункты с кэшем и cookies и нажать на кнопку для старта очистки.
- Ошибка 403 Forbidden возникает и тогда, когда пользователь пытается открыть страницу, для доступа к которой сначала надо осуществить вход в систему. Если у вас есть профиль, просто войдите в него и попробуйте вновь загрузить нужную страницу.
- Если вы заходите со смартфона, попробуйте отключить функцию экономии трафика в браузере. Она находится в настройках, в мобильном Google Chrome под нее отведен отдельный раздел.
- Последний шаг – подождать. Когда ни один способ не помогает, значит, неполадки возникли именно на сайте. Возможно, его владелец уже ищет способы решения проблемы и приступает к их исполнению, но это может занять какое-то время. Пользователям остается только дождаться, когда все работы будут завершены.
Еще одна допустимая причина появления ошибки сервера 403 – доступ к сайту запрещен для определенного региона или страны, в которой вы находитесь. Бывает и такое, что сайт доступен для использования только в одной стране. Если вы используете VPN, попробуйте отключить его и перезагрузите страницу. Вдруг получится все исправить.
Если ничего из вышеперечисленного не сработало, рекомендуется обратиться к владельцу сайта. Есть вероятность, что никто не знает о возникшей проблеме, и только ваше сообщение может изменить ситуацию.
Как появляется ошибка 403
Это наиболее распространенные названия 403 ошибки:
- 403 Forbidden
- HTTP 403
- Доступ запрещён: у вас нет прав доступа к на этом сервере
- Forbidden
- Ошибка 403
- HTTP Error 403.14 — Forbidden
- Ошибка 403 — Forbidden
- Ошибка HTTP 403 — Forbidden
Ошибка 403 Forbidden отображается внутри окна браузера. 403 ошибка, как и все ошибки этого типа, могут появляться в любом браузере в любой операционной системе .
В Internet Explorer веб-сайт отказался показывать это сообщение веб-страницы, указывающее на ошибку 403 Forbidden. В строке заголовка IE должно быть написано 403 Forbidden или что-то подобное.
403 ошибки, полученные при открытии ссылок с помощью программ Microsoft Office, создают сообщение «Невозможно открыть ». Не удается загрузить запрошенную вами информацию в программе MS Office.
Центр обновления Windows также может сообщать об ошибке HTTP 403, но он будет отображаться как код ошибки 0x80244018 или со следующим сообщением: WU_E_PT_HTTP_STATUS_FORBIDDEN .
Ошибка 403 Forbidden Nginx
Итак, ошибка 403 forbidden nginx 1.4 6 Ubuntu может возникать в таких случаях:
- Пользователь заблокирован на сервере с помощью директивы deny в конфигурации nginx;
- Доступ к данному ресурсу разрешен только с определенного IP адреса;
- Пользователь пытается получить доступ к папке, отображение содержимого которой запрещено;
- Nginx не может прочитать содержимое запрашиваемого файла в файловой системе;
- Файл index не найден в каталоге.
Это основные причины, которые встречаются наиболее часто. Как видите, две последние из них представляют из себя проблему. Рассмотрим как ее решить.
Неверно выставлены права
Если права на файл, который пытается получить пользователь выставлены неправильно, то будет выдана такая ошибка. Необходимо, чтобы у Nginx были права не только на чтение этого файла, но и на чтение все родительских каталогов. Это можно проверить командой:
Для всех элементов пути должен быть установлен флаг «r», чаще всего лучше подходят права 644, то есть, владелец может все, а группа и остальные только читать. Если права не соответствуют, то вы нашли проблему и осталось только исправить права с помощью chmod. Например:
Вот так должно быть:
Также обратите внимание на владельца файлов и папок. Если nginx должен иметь возможность выполнять туда запись, то, возможно есть смысл сделать владельцем пользователя nginx или позже получите другую ошибку
Также, если с правами все хорошо, но ошибка не решена попробуйте отключить SELinux, возможно, эта служба мешает Nginx получить доступ к файлам.
Если вы используете PHP и получаете такую ошибку, то еще нужно проверить может ли Nginx получить доступ к сокету обработчика PHP. Желательно, чтобы php-fpm запускался с той же группой, что и nginx, потому что права, по умолчанию, для доступа к сокету 660 (для группы и для владельца). Поэтому проверьте поля listen.owner и listen.group в файле /etc/php5/fpm/php-fpm.conf.
Также можно попытаться использовать сетевой сокет и подключаться к порту, а не файлу.
Неверно настроен index
Файл index открывается по умолчанию при запросе папки на сервере, в которой он находится. Если такого файла в папке нет или он настроен неправильно в конфигурационном файле nginx, то программа попытается отобразить содержимое папки, а это по умолчанию запрещено, поэтому вы получите 403 Foribden.
Чтобы решить проблему убедитесь, что файл index.html, index.php или как он у вас называется, находится в нужно папке, в той, которую вы запрашиваете. Проверьте конфигурационный файл и убедитесь, что в нем указана директива Index с правильным именем и расширением файла:
Если в директиве указаны только файлы html, а вы используете php, то уже понятно почему программа не может найти то, что нужно. Просто добавьте имя файла в директиву:
Точно так же, если вы использовали python скрипт, то нужно добавить его расширение.
What are the common reasons for 403 error?
Как мы кратко объяснили ошибку 403 выше, теперь мы объясним, как пользователь может попасть в ошибку 403 по любой из следующих причин.
List of Reasons for 403 error
Причина 1: защита Hotlink
Что такое хотлинкинг? Горячие ссылки украдут чью-то пропускную способность, связавшись с активами их сайтов, такими как изображения, видео и т. Д.
Чтобы объяснить это далее, предположим, что владелец веб-сайта 1 размещает на своем сервере изображения или видео высокого разрешения.
Владелец веб-сайта 2 впечатлен качеством контента и решает использовать их на своем веб-сайте.
Теперь вместо размещения этих изображений непосредственно на своем сервере он связывает их с сервером веб-сайта 1.
Технически это будет работать абсолютно нормально, и при просмотре веб-сайта 2 пользователь не сможет сразу сказать, использует ли сайт хотлинкинг.
Это позволяет сэкономить много ресурсов для веб-сайта 2, но при этом происходит кража ресурсов веб-сайта 1 и может ухудшить качество обслуживания сервера веб-сайта 1.
Чтобы избежать таких ситуаций, владелец веб-сайта 1 может реализовать зону рефереров.
Это ограничит хотлинкинг и вернет ошибку 403 в случае хотлинкинга.
As this is a server to server restriction, the end-user cannot do much in this case, however, the owners can resolve the issue by hosting the content on their own server.
Обратите внимание, что неэтично использовать сторонние ресурсы без их разрешения
How to fix 403 error by Hotlink Protection?
To set up Hotlink protection in cPanel, head to Security < Hotlink Protection:
Отсюда вы можете включить или отключить защиту от хотлинка:
Теперь, если вы являетесь владельцем сайта website1 и website2, вы можете отключить защиту хотлинков для своего сайта, чтобы связать контент с вашим сайтом и с него.
Следующий скриншот будет разработан для вас:
Причина 2: плохие разрешения
Другой наиболее распространенной причиной 403 запрещенных ошибок является неправильная настройка прав доступа к файлу.
Чтобы решить такие проблемы, владелец должен настроить разрешения, как указано ниже:
- Динамический контент: 700
- Папок: 755
- Статическое содержимое: 644
How to fix 403 error due to BadPermissions?
Чтобы настроить разрешение, выполните следующие действия:
1. Войдите в свою cPanel, используя указанный URL-адрес и назначенные учетные данные для входа.
2. Щелкните значок «Диспетчер файлов» в поле «Файлы».
3. В левой части открывшегося окна вы увидите права доступа ко всем файлам и папкам.
4. Убедитесь, что разрешения для папки public_html равны 750, как показано ниже:
Если это 750, перейдите к следующему устранению неполадок, иначе следуйте инструкциям:
a. Choose the public_html folder > click on the Change Permissions icon
b. Set up permissions to 750 > Save.
с. Очистить кеш браузера
д. Очистить локальный кеш DNS
Причина 3: скрытые файлы / неправильный URL
Доступ к скрытым файлам не должен быть общедоступным, и поэтому сервер ограничивает доступ для всех.
Когда пользователь пытается получить доступ к скрытым файлам, выдается ошибка 403.
Аналогично, для некоторых серверов, если пользователь вводит недопустимый URL-адрес преднамеренно или непреднамеренно, может появиться сообщение об ошибке 403.
Это может варьироваться от сервера к серверу и зависит от того, что пользователь ввел, например, вы можете увидеть ошибку, если вы введете каталог папки вместо пути к файлу.
Причина 4: правила IP
Как указывалось ранее, ошибка 403 возникает в основном из-за ошибки аутентификации.
Пользователи могут видеть 403 правила из-за любых правил IP Deny, определенных в cPanel.
В этом случае проверьте правила в cPanel, чтобы убедиться, что вы не блокируете свой собственный диапазон IP.
Правила IP очень полезны, если вам нужно заблокировать доступ для определенных пользователей.
Значения кодов ответов сервера
Код состоит из трех цифр и начинается с 1-5 в зависимости от группы, к которой принадлежит. После числового обозначения есть приписка на английском, которая поясняет его значение.
Принадлежность кода к группе определяется по первой цифре:
- 1— — информационный код, отвечающий за передачу данных.
Такие коды временны и показывают, что запрос принят и обрабатывается. - 2— — код успешной обработки запроса.
Сервис получил и обработал запрос. - 3— — код редиректа.
Сервер сигнализирует, что для выполнения запроса нужно предпринять дополнительные действия, к примеру, перейти на другой адрес. - 4— — клиентская ошибка.
Ошибка на стороне клиента. Возможно, пользователь что-то сделал неправильно, и поэтому запрос не может быть успешно обработан. - 5— — серверная ошибка.
По какой-то внутренней причине сервер не может выполнить пользовательский запрос.
Коды ответов, сигнализирующих об ошибке, содержат информацию об их причинах. Отслеживать ошибки и устранять их можно по лог-файлам сервера — в логах содержится детальная информация о проблемах.
Finding Error Logs
If you know exactly where the error logs of your Nginx server are, you can skip onto the next section. If you’re not sure where to find the error logs of your Nginx server, then be sure to continue this section.
The path for error logs can change a lot depending on how Nginx was installed on the server and the Linux distribution. If you do not know where your error logs are and you have a hard time going through Nginx configuration, we can use a very small and useful Linux tool with the name of which gives us all the open files associated to a specific process. This will help us find the error log for your web server.
The first step of this is to check for the process ID of the main Nginx process, you can run the following command and except output somewhat similar to the one indicated below:
The first column of each row is the process ID, as we can see, the main/master process ID is in this case, however this will change in every system. Once you have the process ID, you will be able to use the too to get all open files associated to this process by running the following. We’ve trimmed the output to the part you should be looking for, as there might be a lot more data when you run that command:
As you can see from the above output, we can see that one of the files that are open by this Nginx installation is which (by the file name) does look like an error log. We’ve now identified the path of our Nginx error log and we can move onto finding the reason behind our pesky HTTP error.
Полное резервное копирование WordPress
Перед тем, как начать делать что-либо, настоятельно рекомендуется сделать полную резервную копию вашего WordPress сайта.
Чтобы сделать это, сначала нужно войти на свой сервер через SSH.
Затем перейдите к корневой директории WordPress. Например, она может быть расположена по адресу: /var/www/html/wordpress/.
Для того, чтобы сделать полную резервную копию архивированного сайта на WordPress, вы можете выполнить следующую команду:
tar -cpzf wp-backup.tar.gz /var/www/html/wordpress/
Кроме того, вы также должны сделать резервную копию базы данных. В базе данных хранятся вся информация о вашем сайте, как посты, страницы, комментарии, учетные записи пользователей, конфигурации плагинов и т.д.
Для того, чтобы сделать полную резервную копию базы данных, вы можете использовать следующую команду, а затем указать свой пароль базы данных:
mysqldump -u db_user -p db_name > wp_db_backup.sql
Убедитесь в том, чтобы изменить wp-user и wp-database в соответствии с фактическим пользователем базы данных и имя базы данных.
Если вы не уверены в информации в вашей базе данных, которая в данный момент подключена к вашему WordPress сайту, вы можете проверить файл wp-config.php внутри WordPress корневого каталога и найти там следующие строки:
define('DB_NAME', 'db_name'); define('DB_USER', 'db_user'); define('DB_PASSWORD', 'db_password')
Теперь у нас есть полная резервная копия нашего WordPress сайта, и мы можем двигаться дальше, чтобы исправить ошибку 403 Forbidden в WordPress.
Отладка на распространённых платформах
Если вы используете на сервере распространённые пакеты программ, которые выдают ошибку 400 Bad Request, изучите стабильность и функциональность этих платформ. Наиболее распространённые системы управления контентом, такие как WordPress, Joomla! и Drupal, хорошо протестированы в своих базовых версиях. Но как только вы начинаете изменять используемые ими расширения PHP, очень легко спровоцировать непредвиденные проблемы, которые выльются в ошибку 400 Bad Request.
Откатите последние изменения
Если вы обновили систему управления контентом непосредственно перед появлением ошибки 400 Bad Request, рассмотрите возможность отката к предыдущей версии, которая была установлена, как самый быстрый и простой способ убрать ошибку 400 bad request.
Аналогично, любые расширения или модули, которые были обновлены, могут вызывать ошибки на стороне сервера, поэтому откат к предыдущим версиям этих расширений также может помочь.
Но в некоторых случаях CMS не предоставляют возможности отката к предыдущим версиям. Так обычно происходит с популярными платформами, поэтому не бойтесь, если вы не можете найти простой способ вернуться к использованию старой версии той или иной программной платформы.
Удалите новые расширения, модули или плагины
В зависимости от конкретной CMS, которую использует приложение, имена этих компонентов будут различаться. Но во всех системах они служат одной и той же цели: улучшение возможностей платформы относительно её стандартной функциональности.
При этом имейте в виду, что расширения могут так или иначе получать полный контроль над системой, вносить изменения в код PHP, HTML, CSS, JavaScript или базу данных. Поэтому мудрым решением может быть удаление любых новых расширений, которые были недавно добавлены.
Проверьте непреднамеренные изменения в базе данных
Даже если удалили расширение через панель управления CMS, это не гарантирует, что внесенные им изменения были полностью отменены. Это касается многих расширений WordPress, которым предоставляется полный доступ к базе данных.
Расширение может изменить записи в базе данных, которые «не принадлежат» ему, а созданы и управляются другими расширениями (или даже самой CMS). В подобных случаях модуль может не знать, как откатить назад изменения, внесенные в записи базы данных.
Я лично сталкивался с такими случаями несколько раз. Поэтому лучшим путём будет открыть базу данных и вручную просмотреть таблицы и записи, которые могли быть изменены расширением.
nginx 403 Forbidden Error hosting in User Home Directory
runtime environment
nginx -v nginx version: nginx/1.0.15 uname -a Linux ampedservice 2.6.32-279.el6.x86_64 #1 SMP Fri Jun 22 12:19:21 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux cat /proc/version Linux version 2.6.32-279.el6.x86_64 (mockbuild@c6b9.bsys.dev.centos.org) (gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Fri Jun 22 12:19:21 UTC 2012 rake about MANUAL_GC is enable ... About your application's environment Ruby version 1.9.3 (x86_64-linux) RubyGems version 1.8.25 Rack version 1.4 Rails version 3.2.14 Action Pack version 3.2.14 Active Resource version 3.2.14 Action Mailer version 3.2.14 Active Support version 3.2.14 Application root /home/gxdevelop/dev/ampedservice
how I config the application
$ cat /etc/nginx/nginx.conf # For more information on configuration, see: # * Official English Documentation: http://nginx.org/en/docs/ # * Official Russian Documentation: http://nginx.org/ru/docs/ user nginx; worker_processes 1; error_log /var/log/nginx/error.log; #error_log /var/log/nginx/error.log notice; #error_log /var/log/nginx/error.log info; 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 "$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 0; keepalive_timeout 65; #gzip on; # Load config files from the /etc/nginx/conf.d directory # The default server is in conf.d/default.conf include /etc/nginx/conf.d/*.conf; }
ampedservice.conf
upstream ampedservice_unicorn { server unix:/tmp/unicorn.ampedservice.sock fail_timeout=0; # server localhost:8888 max_fails=3 fail_timeout=5 weight=3; #server localhost:9999 max_fails=3 fail_timeout=5; } server { listen 80;# default deferred; server_name amped.guanxi.me; root /home/gxdevelop/dev/ampedservice/public; # individual nginx logs for this ampedservice vhost access_log /var/log/nginx/ampedservice_access.log; error_log /var/log/nginx/ampedservice_error.log; location ^~ /assets|ampedservice_assets/ { gzip_static on; expires max; add_header Cache-Control public; } try_files $uri/index.html $uri @unicorn; location @unicorn { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_redirect off; proxy_pass http://ampedservice_unicorn; } error_page 500 502 503 504 /500.html; client_max_body_size 4G; keepalive_timeout 10; }
My first suspicion was that this was a permissisons problem. However, when I run I see
-rw-rw-r-- 1 gxdevelop gxdevelop 1.8K Aug 10 18:12 /home/gxdevelop/dev/ampedservice/public/aboutuscn.html
which looks right to me? Even running so that the permissions are
-rwxrwxrwx 1 gxdevelop gxdevelop 1.8K Aug 10 18:12 public/aboutuscn.html
does not help. does not produce any errors either and I’m sure the symlink in
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful
So I’ve been at this for a few hours and I’m now wondering what is so special about my user directory that I cannot serve anything inside of it? Ubuntu encrypts home directories these days? Could that be the problem? I also have this issue on an EC2 Ubuntu 12.04 instance (don’t know if user directories are encrypted there)
Заключение
Следуя данным шагам, вы легко сможете избавиться от ошибки 403 forbidden error. Данная ошибка довольно раздражающая, и не позволяет вам получить доступ к вашему сайту. Однако наша пошаговая инструкция поможет вам исправить данную ошибку.
Надеемся, что наше руководство было для вас полезным и достаточно простым,чтобы следовать его инструкциям. Чтобы узнать о WordPress больше, посетите страницу руководств по WordPress.
Пытаюсь поднять рельсы на сервере с убунтой. Ngnix+Unicorn+Capistrano. Все задеплоил, хочу для теста сделать открытие по айпи серверу. В итоге при открытии — 403 forbidden.В логах nginx — directory index of «/home/deployer/www/my_app/current/public/» is forbidden,
На папку пробовал права и 755 и 777. Группа www-data.
nginx конфиг
upstream project_name_rails{ server unix://home/deployer/www/my_app/shared/tmp/unicorn.socket;}
server{ listen 80; server_name *айпи*; root /home/deployer/www/my_app/current/public;
access_log /home/deployer/www/my_app/shared/log/nginx.access.log; error_log /home/deployer/www/my_app/shared/log/nginx.error.log;
location /public { autoindex on; }}
В чем может быть проблема? Заранее спасибо.
Вопрос задан более года назад 11232 просмотра
Подписаться 3 2 комментария
Пригласить экспертаОтветы на вопрос 4
Murmurianez Алексей @Murmurianez JavaScript developer Сейчас дам хреновый ответ, но он поможет двинуться в правильном направлении.
В самом начале nginx.conf есть строчка user www-data; www-data это группа пользователей с чьими правами будет запускаться nginx. Хреновая часть ответа: чтобы не мучаться можно прописать: user your_root_user_name; Оно заработает, но это конечно не для продакшена, но для какого-нибудь тестового чтобы голову не морочить может быть и ОК. А по хорошему, конечно, сделайте нормальную группу пользователей с нормальным правами для запуска. Ответ написан 21 июля 2015 Нравится 1 1 комментарий
neck_varentsov @neck_varentsovПривет!Была такая-же проблема, ругался ошибкой 403, из-за конструкции типа этой
location /public { autoindex on; }
Вот мой конфиг:
server { listen 80 default_server; # listen :80 default_server ipv6only=on; server_name localhost;
passenger_enabled on; rails_env production; root /home/deploy/project/current/public;
error_page 500 502 503 504 /50x.html; location = /50x.html { root html; }}
Ответ написан более года назадНравится Комментировать
Антон @antenkoWeb-разработчикБыла такая же проблема. С правами всё было в порядке, начиная с / до папки с проектом.Помогла командаsetenforce PermissiveОтвет написан 01 апр. 2015Нравится Комментировать
hudson hudson @hudsonНе совсем вовремя — но может кому-то пригодится. Отключите SeLinux… Та же ерунда может быть из-за него (https://access.redhat.com/documentation/en-US/Red_…)Ответ написан 25 мая 2015Нравится Комментировать
Ваш ответ на вопросВойдите, чтобы написать ответВойти через TM IDПохожие вопросы
postgresql Postgresql +4 ещё Почему ROR не коннектиться к базе postgresql посте рестарта базы? 3 подписчика 01 февр. 116 просмотров 1 ответ nginx Nginx +3 ещё Rails4, как задать relative_url_root отличный от ‘/’? 2 подписчика 23 янв. 88 просмотров 1 ответ nginx Nginx +2 ещё Как рельсовое приложение заставить работать по https? 1 подписчик 20 дек. 2015 145 просмотров 1 ответ postgresql Postgresql +4 ещё Как организовать кластер для ruby on rails приложения? 4 подписчика 14 дек. 2015 308 просмотров 1 ответ ruby Ruby +2 ещё Как обрабатывать запросы для поддоменов в Rails приложении? 2 подписчика 08 дек. 2015 115 просмотров 2 ответа nginx Nginx +2 ещё Как сделать заглушку на время технических работ? 3 подписчика 22 нояб. 2015 243 просмотра 2 ответа nginx Nginx +3 ещё Как сделать перезапуск Unicorn, с целью обновления движк