Konstantin GARSHENIN
По нашей схеме.
Цели улучшения
Маскировка: сделать так, чтобы ошибочные подключения выглядели как легитимный веб‑сайт.
Снижение подозрений: избежать типовых ошибок (например, «SSL certificate mismatch»), которые выдают прокси.
Гибкость: предоставить разные ответы для разных сценариев (неизвестный домен, подключение по IP и т. д.).
Безопасность: минимизировать раскрытие информации о внутренней инфраструктуре.
А может проще любое невалидное sni или подключение по ip просто сразу дропнуть на srv1
А может так ..
.....
upstream fallback_backend { server 127.0.0.1:8443; }
server {
listen 443;
proxy_pass $backend;
ssl_preread on;
}
}
http {
server {
listen 8443 ssl default_server;
server_name _;
ssl_certificate /etc/nginx/ssl/wildcard.crt; # wildcard или multi‑domain
ssl_certificate_key /etc/nginx/ssl/wildcard.key;
location = / {
return 200 "Service is online. Use domain name for access.\n";
add_header Content-Type text/plain;
}
location /status {
access_log off;
return 200 "OK";
add_header Content-Type text/plain;
}
}
}
Так сайт же живет на srv2 по нашей схеме.
Ты же сам сказал зачем левые запросы проксировать. Пусть на srv2 попадают только валидные.
Тьфу на тебя .. Ты запутался.. Мы не дропаем левые на srv1. Мы отдаем сайт заглушку с сертификатом вилдкат. Глянь раньше.
Все решили. Супер. Запомни для нашей схемы.
Бубны у нас у всех разной системы .. 🤣