Эта схема не решает то о чем выше. Это некоторый аналог то, что описал я (и это уже есть давно и рабочие решения). Тут речь что делать если домен того центрального сайта заблокируют. :)
Но тут уже у меня "нет идей", т.к. тема в принципе не интересна - у меня нет интереса к созданию проектов которые потенциально могут быть заблокированными. Идей и без того хватает.
fastcgi_intercept_errors off;
или добавить в секцию php:
location @php { fastcgi_intercept_errors off;...
проверить и перегрузить конфиг
sudo nginx -t && sudo systemctl reload nginx
Заменил в файле 404.php как советовал уважаемый master32 стоку
Всё равно редиректит на 404.html...
sudo nginx -T 2>&1 | grep -nC 4 -E 'fastcgi_intercept_errors|error_page'
http_response_code(404); require $_SERVER['DOCUMENT_ROOT'] . '/404.php'; exit;
https://bitrixum.ru
Не, я ответ то знаю где причина, просто мне интересна логика других людей. Мало ли, а вдруг новая идея, которую я не обдумывал.
Про фильтры гугла не понял. Проблема не в том что есть сайт в поиске или нет, а в том что он фактически недоступен пользователю.
Низкий сетевой уровень это ты про что?
ты совсем не так понял)чтоб посмотреть/изучить, как выглядит блокировка домена РКНом, надо зайти в гугл и найти примеры по запросу "списки заблокированных РКН доменов"Низкий сетевой уровень позволяет описать, в какой момент сайт фактически недоступен пользователю
если это блокировка домена, то это будет видно и это можно описать скинув примеры ответаа именно, что я наблюдаю - успешное сетевое рукопожатие клиента с сервером есть, а далее все начинает ломаться на разных сетевых этапахтут некоторые специализды писали, что надо понизить tls до 1.2, но логики своих действия не расписывают (просто не знают, а совет взяли с хабра)это возможно сработало бы, если предположить, что длина ответа tls 1.2 короче 1.3 и фильтр пропускает такой ответ, но...