Режими SSL/TLS Cloudflare: Flexible, Full, Full Strict

Cloudflare підтримує чотири режими SSL/TLS. Кожен описує, як зашифрований трафік між відвідувачем, Cloudflare і вашим сервером. Неправильний вибір призводить або до нескінченних редиректів, або до незашифрованої ділянки шляху між Cloudflare і сервером — а це відкритий канал для перехоплення паролів і кук сесії, навіть якщо браузер відвідувача показує замок в адресному рядку.

Режими SSL/TLS

Чому Full (Strict) — правильний вибір

• Трафік зашифрований на всьому шляху, а не лише від браузера до CDN.
• Захист від атак «людина посередині» між Cloudflare і сервером — критично, якщо сервер стоїть не у вашому дата-центрі.
• Стандарт безпеки для production: відповідає вимогам PCI DSS і більшості політик безпеки.

Як увімкнути Full (Strict)

Cloudflare Dashboard → SSL/TLS → Overview → Full (strict). На сервері має бути валідний SSL-сертифікат — підійде Let's Encrypt або сертифікат від Cloudflare.

Розбір типових помилок

Коди 520–526 у відповіді Cloudflare майже завжди пов'язані саме з режимом SSL/TLS; повний список кодів розібрано у статті помилки Cloudflare 520-525.

• ERR_TOO_MANY_REDIRECTS — сервер налаштовано редиректити HTTP на HTTPS, а Cloudflare в режимі Flexible підключається до сервера по HTTP: виходить нескінченна петля «редирект → HTTP → редирект».
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH — на origin-сервері вимкнено сучасні протоколи TLS 1.2/1.3 або застарілий OpenSSL не підтримує потрібні шифри для рукостискання з Cloudflare.
• 521 Web Server Is Down у режимі Full (Strict) — сервер слухає лише HTTP на 80 порту, а HTTPS на 443 не відповідає: Cloudflare намагається достукатися по HTTPS і отримує відмову з'єднання.
• 526 Invalid SSL Certificate — сертифікат на сервері прострочений, самопідписаний або виписаний не на той домен, а режим стоїть Full (Strict), який вимагає валідності ланцюга.
• 525 SSL Handshake Failed — Cloudflare не змогла домовитися з сервером про протокол TLS під час рукостискання; зазвичай причина в тому, що на сервері вимкнено всі протоколи, які підтримує Cloudflare, або порт 443 зайнятий іншим сервісом.

Порівняння джерел сертифіката для origin-сервера

Примусовий HTTPS через Cloudflare

SSL/TLS → Edge Certificates → Always Use HTTPS → On. Cloudflare редиректитиме HTTP на HTTPS на рівні CDN, ще до того, як запит дійде до сервера — це знімає навантаження з origin і виключає ризик неправильного редиректу в застосунку.

Коли Full (Strict) не підходить

• Сервер лише розгортається і валідного сертифіката ще немає — тимчасово використовуйте Full із самопідписаним, але не Flexible, щоб не ганяти трафік відкритим текстом.
• Origin стоїть за динамічним IP без DNS-запису, на який можна випустити Let's Encrypt — тоді єдиний практичний варіант це Cloudflare Origin Certificate, прив'язаний до IP, а не до домену.
• Legacy-застосунок примусово перевіряє відповідність імені сертифіката і не розуміє сертифікат від нестандартного CA — іноді доводиться тимчасово тримати Full замість Strict, доки застосунок не оновлять.

Як перевірити, що режим налаштовано вірно

# Перевіряємо сертифікат, який бачить зовнішній клієнт
curl -vI https://example.com/ 2>&1 | grep -E 'SSL|subject|issuer'

# Перевіряємо, що HTTP редиректить на HTTPS одним стрибком
curl -I http://example.com
# Очікуємо: HTTP/1.1 301, Location: https://example.com/

# Перевіряємо сертифікат сервера напряму, минаючи Cloudflare (через hosts-файл)
curl -vI --resolve example.com:443:SERVER_IP https://example.com/ 2>&1 | grep issuer

Якщо перша команда показує сертифікат Cloudflare, друга — один редирект без петлі, а третя підтверджує валідний сертифікат на самому сервері, режим Full (Strict) налаштовано коректно.