- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов

В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Всем привет!
После начала проблем с CF, изучив тему аналогов для проксирования, решил организовать аналог следующим образом:
- Арендовал VPS на котором развернул Nginx (так как больше с ним работаю). В администрировании я среднячок. Не нуль, но и не профи.
Итого на старте имеем:
1) Backend - hetzner выделенный сервер nginx с кучкой сайтов.
2) Reverse proxy на nginx с РФ айпишником. Его задача скрывать реальный ip от абуз и неожиданных блокировок, а также иметь ряд WAF-правил для блокировки ботни.
Теперь к проблеме.
а) На Reverse proxy создал конфиг для нужного сайта. Там же выпустил SSL. Прочитал, что вроде как так правильнее, чтобы ssl обрабатывался на фронте. Нужные заголовки передаются как надо. По логам вроде как на backend все поступает корректно.
б) Если оставляем SSL на Backend, то начинаются редиректы постоянные. Пока не смог победить. Пока основные подозрения на Backend, где-то он походу создает лишние редиректы.
в) Если же отключить SSL на Backend , то тогда сайты стартуют, но поломанные, так как CSS и JS не загружаются и отдают blocked: mixed-content. Эту проблему победить удалось с помощью гопоты - он предложил следующий костыль - прописать в wp-config строчку:
сбросил кэш и вроде все завелось.
Собственно затык в том, что как лучше? Оставить вариант в)? Тот же ChatGPT пишет, что это решение - обманка и оно не идеальное. В идеале, по его словам, на backend тоже включить SSL.
Собственно, вопрос к знатокам - как лучше? И если лучше вариант б) - ssl на backend, то куда смотреть в случае с nginx, чтобы решить проблему редиректов? С гопотой пытаюсь уже третий день победить эти долбанные редиректы, но все никак.
Если данные передаются по незащищенному протоколу (не важно между пользователем или между серверами), то в теории они могут быть скомпрометированы. Например, пароль администратора вашего WP.
Но это в теории. Проверять это на практике или нет, только вам решать.
Лично моё мнение - стоит включить.
В идеале, по его словам, на backend тоже включить SSL.
не нужен ssl на бекенде, обмани его чтоб он там где надо генерил правильные пути и все. ssl там только ненужная нагрузка на оба сервера с нулевой пользой.
Пока основные подозрения на Backend, где-то он походу создает лишние редиректы.
Проверять настройки сервера, нет ли там редиректа с http на https - зачастую включают при получении SSL.
WP тоже такую настройку имеет, вангую, что редиректы наложились, поэтому только проверять.
Редирект с http на https и основной SSL сайта должны быть только на прокси.
Первый вариант более разумный и правильный, с т.з. безопасности.
Первый вариант более разумный и правильный, с т.з. безопасности.
в) Если же отключить SSL на Backend
Немного запутался) Можешь не первый вариант указать, а Б или В правильный?)
б) Если оставляем SSL на Backend, то начинаются редиректы постоянные.
в) Если же отключить SSL на Backend
Немного запутался) Можешь не первый вариант указать, а Б или В правильный?)
Вам ИИ правильно написал про заголовок HTTP_X_FORWARDED_PROTO. Как правильно он настраивается на WP, я не в курсе, но дело в нём.
б) Если оставляем SSL на Backend, то начинаются редиректы постоянные.
в) Если же отключить SSL на Backend
Немного запутался) Можешь не первый вариант указать, а Б или В правильный?)
Смотрите сами, у вас получилась ситуация, что SSL установлен и на Reverse proxy, и на Backend - в итоге получили цикл редиректов.
Теоретически на Backend должен быть SSL, чтобы защитить канал, но SSL должен быть обычный самоподписанный.
А вот на Reverse proxy должен быть установлен SSL выданный для сайта, так как к Reverse proxy обращаются все браузеры.
Короче, вам в обих случаях нужно проверять настройки Nginx - наверняка на обоих стоит редирект, раз SSL на обоих установлен.
Редирект с http на https нужно оставлять только на Reverse proxy, а на Backend все редиректы удалять из настроек Nginx.
Короче, делайте по варианту SSL для сайта на Reverse proxy, Backend без SSL.
Ничего страшного в этом нет, иначе вы запутаетесь...
Если настраивать по уму, то нужен доступ к обоим серверам, чтобы смотреть настройки Nginx у обоих.
Если юзать SSL на обоих серверах, то там еще и Политики нужно добавлять в заголовок: add_header Access-Control-Allow-Origin "сайт или IP зависит от настроек";, иначе будет проблема со скриптами, как щас у вас...
PS: А вообще, лучше вот Кодекс WP почитайте, там всё уже разжевано, это лучше чем советы GPT.
Там же и правильные заголовки в настройках Nginx указаны...
PS: А вообще, лучше вот Кодекс WP почитайте, там всё уже разжевано, это лучше чем советы GPT.
Благодарю!