Cloudflare перед сервисом

Если у тебя домен на Cloudflare — это самый предсказуемый фронт по поведению: динамика не кешируется, методы и заголовки проходят из коробки. Показываю настройку за четыре шага и объясняю, почему для РФ-аудитории он идёт вторым номером, а не основным. Практика.

Где Cloudflare хорош, а где нет

Общую базу CDN-фронтинга (XHTTP-инбаунд на origin, режимы GET/POST, nginx) разбирали в теории и в практике Yandex — она общая для всех провайдеров. Здесь только специфика Cloudflare.

Cloudflare — эталон предсказуемости. Но у него полярные плюсы и минусы, и от них зависит, куда его ставить.

Чем хорош:

• Не кеширует POST и long-GET по умолчанию — динамика проходит как есть.
• XHTTP работает даже там, где нет WS/gRPC.
• Бесплатный план, мировой охват.

Чем неудобен из РФ:

• DNS Cloudflare из РФ медленный.
• Оплата из РФ недоступна.

Вывод: для российской аудитории как основной фронт он ненадёжен. Его роль — эталон для зарубежа и резерва. Для РФ-аудитории комбинируй: прямой Self-steal Reality основным + XHTTP за CDN резервом, а из РФ-CDN бери Yandex.

Настройка за четыре шага

Если домен уже на NS Cloudflare, весь фронт ставится быстро.

Шаг 1. DNS-запись в режиме Proxied.

Заводишь запись cdn (A → IP ноды) и включаешь Proxied (оранжевое облако). Именно оранжевое облако направляет трафик через сеть Cloudflare — серое (DNS only) просто резолвит IP напрямую и фронта не даёт.

Шаг 2. SSL/TLS → Full.

В панели Cloudflare: SSL/TLS → Overview → Full. Кеш при этом не трогает POST и long-GET (динамика не кешируется по умолчанию), так что специально отключать кеш, как у РФ-CDN, тут не надо.

Если хочешь подстраховаться и явно запретить кеш на XHTTP-пути — заведи Cache Rule через API (сам путь секретный, поэтому вынесен в плейсхолдер):

curl -X POST \
  "https://api.cloudflare.com/client/v4/zones/ZONE_ID/rulesets/phases/http_request_cache_settings/entrypoint" \
  -H "Authorization: Bearer CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "rules": [
      {
        "description": "Bypass cache for XHTTP path",
        "expression": "(http.host eq \"cdn.your-domain.com\" and starts_with(http.request.uri.path, \"/PATH_XHTTP\"))",
        "action": "set_cache_settings",
        "action_parameters": { "cache": false }
      }
    ]
  }'

И держи в голове главное: режим шифрования должен быть именно Full (strict) — тогда Cloudflare проверяет валидность сертификата на origin. Простой Full (без strict) молча принимает самоподписанный серт и открывает дверь для MITM между CDN и нодой.

Шаг 3. XHTTP в режиме packet-up.

На origin поднимаешь тот же XHTTP-инбаунд, что и для любого CDN (см. общую практику), в режиме packet-up — он самый совместимый. XHTTP проходит через Cloudflare даже там, где WS/gRPC заблокированы.

Шаг 4. Хост в Remnawave.

Создаёшь Host: cdn.your-domain.com:443, path=/xh, режим packet-up, TLS. Клиент коннектится на CDN-домен, Cloudflare тянет с origin.

На что обратить внимание

• Origin закрыть от всех, кроме Cloudflare. Раз клиент ходит только через CDN, прямой доступ к IP ноды не нужен — закрой его фаерволом на диапазоны Cloudflare, чтобы ноду не нашли сканом.
• Путь /xh — секретный. На origin nginx проксирует в Xray только этот путь без буферизации, всё остальное отдаёт сайт-обманку (как в общей практике).
• ECH держи выключенным. Отдельная ловушка: с включённым ECH сайт за Cloudflare из РФ может открываться только через VPN — если origin вдруг стал недоступен из РФ, проверь SSL/TLS → Edge Certificates → ECH → Off.

Итог

Cloudflare — самый беспроблемный фронт, если аудитория зарубежная или он у тебя как резерв. Для РФ он второй номер из-за медленного DNS и недоступной оплаты. Держи его в подписке дополнительным хостом рядом с прямым Reality и РФ-CDN — тогда какой-то канал всегда живой.

Механику CDN-фронта смотри в теории; рабочий РФ-фронт с обходом блокировки POST — в практике Yandex CDN.