dimsog: saloed, да.
Сейчас проверил, на одном VPS у меня сайты только c http, такой проблемы нет. На второй сайты c https и http. И там в браузере ваша проблема воспроизводится. У меня только nginx
дык а очистка кеша браузера должна помогать?
просто если я попытаюсь открыть сайт по https, а потом по http, то он уже редиректит сам с http на https, что бы я ему не делал или я не умею чистить кеш браузера.
AGHost: saloed, разделите обязанности, авторизация к серверам по ключам, никаких паролей не давайте. Если приживется, то выдадите. Повысьте старого админа в должности до "начальника админов", пусть он решает, что выдавать, а что нет.
разделение обязанностей при двух админах не вариант, доджны быть взаимозаменяемость, ради этого и брали второго админа.
авторизация по ключам не везде применима, т.е. львиная доля это сервера клиентов, а там зоопарк систем, технологий и софта.
Попробую, пееревести вопрос в другую плоскость: а как на счет схем хранения логинов\парлолей и совместный доступ к ним? кто какие подходы использует? Сейчас все у одного админа в txt и xls на шифрованном контейнере в дробоксе.
Что самое неприятное, Slowlori атака не оставляет никаких следов, кроме огромного количества открытых cоединений со статусом ESTABLISHED. Не будет никаких записей даже в access_log-е.
никто не подскажет?
Оказывается я выстрелил себе в ногу вот этой настройкой на домене с купленным ssl:
Это включило HSTS для всех субдоменов.
Выключил это вот так
И очистил HSTS кеш Firefox. Теперь порядок.
saloed, да.
Сейчас проверил, на одном VPS у меня сайты только c http, такой проблемы нет. На второй сайты c https и http. И там в браузере ваша проблема воспроизводится. У меня только nginx
дык а очистка кеша браузера должна помогать?
просто если я попытаюсь открыть сайт по https, а потом по http, то он уже редиректит сам с http на https, что бы я ему не делал или я не умею чистить кеш браузера.
А апатч случаем не стоит?
да, за nginx стоит apache
---------- Добавлено 28.03.2017 в 17:14 ----------
Он в любом случае будет отвечать, даже если нет сертификата. .
это работает только в случае, когда на nginx, к которому мы обращаемся, поднят хоть один сайт на https. верно?
нашел в инете первый попавшийся сайт с http и он по https никак не открывается и не откроется, т.к. нечему отвечать там на 443 порту.
saloed, разделите обязанности, авторизация к серверам по ключам, никаких паролей не давайте. Если приживется, то выдадите. Повысьте старого админа в должности до "начальника админов", пусть он решает, что выдавать, а что нет.
разделение обязанностей при двух админах не вариант, доджны быть взаимозаменяемость, ради этого и брали второго админа.
авторизация по ключам не везде применима, т.е. львиная доля это сервера клиентов, а там зоопарк систем, технологий и софта.
Попробую, пееревести вопрос в другую плоскость: а как на счет схем хранения логинов\парлолей и совместный доступ к ним? кто какие подходы использует? Сейчас все у одного админа в txt и xls на шифрованном контейнере в дробоксе.
default via REAL_GATEWAY dev REAL_IF src VIP_ADDRESS metric 100
Спасибо, то что нужно! Всё завелось.
Сделал так
0.0.0.0/0 via REAL_GATEWAY dev REAL_IF src VIP_ADDRESS metric 100
}
saloed, в принципе - да . На практике узнавайте у вашего датацентра чем у ваш случай осложняется.
т.е. чужой? да они вас выключат и не будут разбираться.
попробуйте серый 192.168.*
спасибо, поменяем подальше он неприятностей
saloed, а как долго он не имеет доступа в инет после попытки переключить?
.
может я криво выразился, ситуация следующая:
VIP адрес я с инета вижу, он пингуется, по ssh подключаюсь к VPS.
проблема в том что с VPS я инет не вижу, ничего не пингуется.
Я так подозреваю, что-то с маршрутизацией не так, но с ходу не разобрался что именно. вот решил узнать в принципе такая схема должна\модет работать?
Просто во всех доках и инструкциях, описывается схема, когда интерфейсы eth0 имеют реальный айпишники, а у меня его нет.
"Падает" Апач, т.е. перестаёт отвечать. При этом через 5 мин все само нормализуется.
Ошибка 499 в логах nginx говорит о тот, что клиент не дождался ответа и закрыл соединение, т.е. Апач не ответил вовремя.
По поводу колич. соед. с одного ip, для этого настроен nginx, что бы отсекать такие запросы
limit_conn addr 50;
---------- Добавлено 18.11.2016 в 12:48 ----------
Может nginx долго держит соединение? У апатча keepalive выключен?
Да на апаче выключен,
nginx через 300сек закрывает соединение
proxy_pass http://127.0.0.1:8080;
proxy_redirect off;
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_read_timeout 300;
proxy_buffer_size 16k;
proxy_buffers 32 16k;
limit_req zone=dynamic burst=200;
limit_conn addr 50;
limit_req_log_level notice;
limit_req_status 429;
;14783180']Slowloris?
В access_log загляните.
в acces логах nginx вполне релевантные запросы приходили в это время, но уже получали 499 ответ
насчет slowloris даже не знаю, знаю это:
как его обнаружить?