fix(mera/perimeter): www-формы доменов МЕРА обрывали TLS вместо редиректа #3137

Merged

lekss361 merged 1 commit from fix/3xxx-www-mera-tls into main

2026-08-27 11:18:29 +00:00

lekss361 commented

2026-08-27 11:17:40 +00:00

Owner

Проблема

Клиент, набравший www.meraocenka.ru (или www-форму любого из двух доменов-спутников), видел «сайт не открывается».

A-записи всех трёх www-имён заведены и указывают на прод 188.124.37.140. Но site-блоков под них в Caddy не было. Caddy матчит строго по имени хоста и на неизвестное имя сертификата не выпускает — соединение обрывалось на рукопожатии (TLS alert 80, internal error).

Замер до правки:

хост	код curl
`https://www.meraocenka.ru/`	`000`
`https://www.merahome.ru/`	`000`
`https://www.meraotsenka.ru/`	`000`
`https://www.gendsgn.ru/`	`301` ✅
`https://meraocenka.ru/`	`200` ✅

Коварство в том, что в логах доступа не было ни строки: до HTTP-слоя запрос не доходил, поэтому молчали и метрики, и мониторинг. Проблема не проявилась бы ничем, кроме жалобы клиента.

Решение

Три site-блока с 301 на канонический meraocenka.ru — ровно тот же приём, что у www.gendsgn.ru, который имел свой блок с самого начала и потому работал. {uri} сохраняет путь и query, чтобы короткая ссылка с визитки не теряла ?id=.

Проверка

caddy validate на трёх новых блоках → Valid configuration
caddy fmt разбирает изменённый apps.caddy без ошибок структуры (остаётся лишь предсуществующая претензия к отступам в строке 79 — табы против пробелов, во всём файле)
bash -n на смоуке — ok

Регресс-защита

Смоук периметра дополнен проверкой 5b. Существующая проверка «спутники отдают 301» этот класс поломки не ловила: отсутствие блока проявляется не как 404, а как пустой код ответа, поэтому нужна явная проверка каждого www-имени.

После деплоя Caddy выпустит сертификаты Let's Encrypt на три новых имени автоматически — DNS уже на месте.

Найдено сквозным аудитом периметра 27.08.

## Проблема Клиент, набравший `www.meraocenka.ru` (или www-форму любого из двух доменов-спутников), видел **«сайт не открывается»**. A-записи всех трёх www-имён заведены и указывают на прод `188.124.37.140`. Но site-блоков под них в Caddy не было. Caddy матчит строго по имени хоста и на неизвестное имя сертификата не выпускает — соединение обрывалось на рукопожатии (`TLS alert 80, internal error`). Замер до правки: | хост | код curl | |---|---| | `https://www.meraocenka.ru/` | `000` | | `https://www.merahome.ru/` | `000` | | `https://www.meraotsenka.ru/` | `000` | | `https://www.gendsgn.ru/` | `301` ✅ | | `https://meraocenka.ru/` | `200` ✅ | Коварство в том, что **в логах доступа не было ни строки**: до HTTP-слоя запрос не доходил, поэтому молчали и метрики, и мониторинг. Проблема не проявилась бы ничем, кроме жалобы клиента. ## Решение Три site-блока с `301` на канонический `meraocenka.ru` — ровно тот же приём, что у `www.gendsgn.ru`, который имел свой блок с самого начала и потому работал. `{uri}` сохраняет путь и query, чтобы короткая ссылка с визитки не теряла `?id=`. ## Проверка - `caddy validate` на трёх новых блоках → `Valid configuration` - `caddy fmt` разбирает изменённый `apps.caddy` без ошибок структуры (остаётся лишь предсуществующая претензия к отступам в строке 79 — табы против пробелов, во всём файле) - `bash -n` на смоуке — ok ## Регресс-защита Смоук периметра дополнен проверкой **5b**. Существующая проверка «спутники отдают 301» этот класс поломки не ловила: отсутствие блока проявляется не как `404`, а как **пустой код ответа**, поэтому нужна явная проверка каждого www-имени. После деплоя Caddy выпустит сертификаты Let's Encrypt на три новых имени автоматически — DNS уже на месте. Найдено сквозным аудитом периметра 27.08.

lekss361 added 1 commit 2026-08-27 11:17:41 +00:00

fix(mera/perimeter): www-формы доменов МЕРА обрывали TLS вместо редиректа

CI Trade-In / changes (pull_request) Successful in 7s

Details

CI / changes (pull_request) Successful in 9s

Details

CI Trade-In / backend-tests (pull_request) Has been skipped

Details

CI Trade-In / browser-tests (pull_request) Has been skipped

Details

CI Trade-In / frontend-checks (pull_request) Has been skipped

Details

CI / backend-tests (pull_request) Has been skipped

Details

CI / frontend-tests (pull_request) Has been skipped

Details

CI / openapi-codegen-check (pull_request) Has been skipped

Details

031b4559b9

A-записи www.meraocenka.ru / www.merahome.ru / www.meraotsenka.ru заведены и
указывают на прод, но site-блоков под них в Caddy не было. Caddy матчит строго
по имени хоста и на неизвестное имя сертификата не выпускает, поэтому клиент,
набравший привычное «www.», получал обрыв рукопожатия (TLS alert 80) — для
браузера это «сайт не открывается». В логах доступа при этом ни строки: до
HTTP-слоя запрос не доходил, так что молчали и метрики.

www.gendsgn.ru такой блок имел с самого начала и потому работал — здесь ровно
тот же приём, три отдельных блока с 301 на канонический meraocenka.ru.

Найдено сквозным аудитом периметра 27.08. Проверено: три www-имени резолвятся
в 188.124.37.140, curl до правки возвращал пустой код (000) на всех трёх,
www.gendsgn.ru — 301.

Смоук периметра дополнен проверкой 5b: отсутствие блока проявляется НЕ как
404, а как пустой код ответа, и обычная проверка «спутники отдают 301» такой
регресс не ловила.