Периодически выскакивает 403 ошибка

nginx на фронтэнд. вместо username username там serg-smirnoff serg-smirnoff соответственно этот юзер и имеет все соотв. права.

понятно что ситуация не типовая. потому что если бы она была типовая, то 403 висел бы всегда. и решалось бы все через Options

но 403 появляется внезапно, и далеко не всегда.

---------- Добавлено 20.10.2013 в 18:37 ----------

руками не проверял, проверить можно. но чувствую что с правами и юзерами там все нормально.

А, это уже другой разговор. Всё нужно вытягивать клещами.

Тогда понятно, почему от .htaccess никакого эффекта.

Из чего следует, что вероятно виноват конфиг nginx. Так что нужно смотреть его логи и конфиг.

Для начала можно проверить права на корневую папку сайта, поставить 755. Затем проверить от какого юзера работает nginx и убедится, что этот юзер имеет доступ.

Да имеет он доступ. Если бы проблема была в пользователе, то тогда бы ничего не работало в принципе.

Конфиг nginx

===

user www-data;

worker_processes 2;

timer_resolution 100ms;

worker_rlimit_nofile 8192;

worker_priority -10;

pid /var/run/nginx.pid;

events {

#worker_connections 768;

worker_connections 2048;

use epoll;

# multi_accept on;

}

http {

##

# Basic Settings

##

sendfile on;

tcp_nopush on;

tcp_nodelay on;

keepalive_timeout 5 5;

types_hash_max_size 2048;

# server_tokens off;

# server_names_hash_bucket_size 64;

# server_name_in_redirect off;

include /etc/nginx/mime.types;

default_type application/octet-stream;

##

# Logging Settings

##

access_log /var/log/nginx/access.log;

error_log /var/log/nginx/error.log;

##

# Gzip Settings

##

gzip on;

gzip_min_length 1100;

gzip_disable "msie6";

gzip_vary on;

gzip_proxied any;

gzip_comp_level 3;

gzip_buffers 64 8k;

gzip_http_version 1.1;

gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

client_body_timeout 10;

client_header_timeout 10;

send_timeout 10;

##

# nginx-naxsi config

##

# Uncomment it if you installed nginx-naxsi

##

#include /etc/nginx/naxsi_core.rules;

##

# nginx-passenger config

##

# Uncomment it if you installed nginx-passenger

##

#passenger_root /usr;

#passenger_ruby /usr/bin/ruby;

##

# Virtual Host Configs

##

include /etc/nginx/conf.d/*.conf;

include /etc/nginx/sites-enabled/*;

include /usr/local/ispmgr/etc/nginx.domain;

client_max_body_size 16M;

log_format isp '$bytes_sent $request_length';

server {

server_name schekino.net www.schekino.net;

listen 88.198.199.18;

disable_symlinks if_not_owner from=$root_path/$subdomain;

set $root_path /var/www/serg-smirnoff/data/www/schekino.net;

set $subdomain "";

location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ {

root $root_path/$subdomain;

access_log /var/www/nginx-logs/serg-smirnoff isp;

access_log /var/www/httpd-logs/schekino.net.access.log ;

error_page 404 = @fallback;

}

location / {

proxy_pass http://88.198.199.18:81;

proxy_redirect http://88.198.199.18:81/ /;

proxy_set_header Host $host;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

proxy_set_header X-Real-IP $remote_addr;

}

location ~* ^/(webstat|awstats|webmail|myadmin|pgadmin)/ {

proxy_pass http://88.198.199.18:81;

proxy_redirect http://88.198.199.18:81/ /;

proxy_set_header Host $host;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

proxy_set_header X-Real-IP $remote_addr;

}

location @fallback {

proxy_pass http://88.198.199.18:81;

proxy_set_header Host $host;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

proxy_set_header X-Real-IP $remote_addr;

}

include /usr/local/ispmgr/etc/nginx.inc;

if ($host ~* ^((.*).schekino.net)$) {

set $subdomain ../$1;

}

}

server_names_hash_bucket_size 72;

server_names_hash_max_size 1024;

}

===

Попробуйте такой вариант:

После строчки:

location / {

Добавить:

index index.php;

Если не сработало - попробуйте на всякий перенести новую строчку в конец этого же блока условия корневой локации.

Например после строчки: proxy_set_header X-Real-IP $remote_addr;

т.е. получится так:

proxy_set_header X-Real-IP $remote_addr;

index index.php;

}

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

Еще можно попробовать сменить пользователя www-data на того же, что в апаче. Но это в последнюю очередь.

Ставили какой-то модуль от DDoS на CMS или Apache?

тут бы понять почему nginx делает это иногда. узнать причину. и устранить ее.

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

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

и вот с ними такого не возникает. к чему бы это? )

---------- Добавлено 20.10.2013 в 23:14 ----------

на CMS ставил (ограничитель количества входов в админку), от передобров на админку. но выпилил уже давно. на апач не ставил вроде.

Если всё это возникает в пределах одного впс и главное одной панели управления, то возникает два предположения на выбор:

1) Это глюк. Для некоторых сайтов создались конфиги с каким то багом. Либо, если глючные сайты были последними установленными, то общую конфигурацию шаблонов nginx подпортила установка чего либо в систему.

2) Шаблоны nginx не до конца совместимы с некоторыми движками или с определенными конфигурациями движков.

Попробуйте метод с индексом и юзером. Больше вариантов - пока теряюсь в догадках.

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

попробовал index index.php; проблема не ушла. дело не в том что nginx или apache теряют индекс. дело в том, что им и по какой причине не дает его подгрузить

Для начала бы определится (по логам) кто виноват: nginx or apache. А после уже голову сушить.

---------- Добавлено 20.10.2013 в 23:30 ----------

Отключите все лишние модули в апаче, и все без чего можно обойтись день-два.

---------- Добавлено 20.10.2013 в 23:31 ----------

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

по каким логам? в логах все чисто. в логах никто не виноват )

отключить модули можно. пока не пробовал