301 редирект HTTP на HTTPS: повний гайд для Apache, Nginx, Cloudflare

⏱️ Час читання: ~11 хвилин | 📅 Оновлено: 30 грудня 2025

HTTP у 2026 — це не просто застаріло. Це небезпечно

Браузери позначають HTTP-сайти як "Not Secure". Google знижує їх у пошуку. Користувачі бачать попередження і закривають вкладку. А якщо на сайті є форма — пароль, email, номер картки — всі ці дані летять по мережі відкритим текстом.

Сертифікат SSL/TLS сьогодні безкоштовний (дякуємо Let's Encrypt). Немає жодної причини залишатись на HTTP. Але встановити сертифікат — це половина справи. Друга половина — правильно налаштувати редирект, щоб весь трафік автоматично йшов через HTTPS.

Здавалось би, що тут складного? Додав один рядок у конфіг — і готово. Але на практиці саме тут виникають проблеми: безкінечні петлі редиректів, mixed content, втрата позицій у пошуку через неправильну канонізацію, проблеми з CDN.

У цій статті — як зробити все правильно з першого разу. Конкретні конфіги для Apache, Nginx, Cloudflare. Що може піти не так і як це виправити.

301 редирект: що це і чому саме 301

HTTP-редирект — це інструкція браузеру: "Сторінки тут немає, йди за цією адресою". Код 301 означає "Moved Permanently" — переміщено назавжди.

Чому 301, а не 302 чи 307?

301 (Moved Permanently) — постійний редирект. Пошукові системи передають вагу посилань на нову адресу. Браузери кешують редирект, тому повторні запити йдуть одразу на HTTPS.

302 (Found / Temporary Redirect) — тимчасовий. Пошуковики не передають вагу, бо вважають що це тимчасово. Для HTTP→HTTPS це неправильний вибір.

307 (Temporary Redirect) — теж тимчасовий, але зберігає метод запиту (POST залишається POST). Для звичайного редиректу на HTTPS не підходить.

308 (Permanent Redirect) — як 301, але зберігає метод. Можна використовувати, але 301 більш сумісний зі старими браузерами.

Ланцюжки редиректів: чому це погано

Типова помилка: http://example.com → http://www.example.com → https://www.example.com → https://example.com. Чотири стрибки замість одного.

Кожен редирект — це затримка 50-200 мс. Для мобільних користувачів на повільному з'єднанні це критично. Google рахує це як частину часу завантаження.

Правильно: один редирект одразу на фінальну адресу. Визначтесь, яка версія канонічна (з www чи без), і редиректьте все на неї.

Apache: правильна конфігурація

Для Apache рекомендований метод — через конфігурацію VirtualHost, а не .htaccess. VirtualHost працює швидше, бо .htaccess перечитується при кожному запиті.

Базовий редирект через VirtualHost

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    
    Redirect permanent / https://example.com/
</VirtualHost>
<VirtualHost *:443>
    ServerName example.com
    
    SSLEngine on
    SSLCertificateFile /etc/ssl/cert.pem
    SSLCertificateKeyFile /etc/ssl/key.pem
    
    DocumentRoot /var/www/html
</VirtualHost>

Різниця між Apache 2.2 та 2.4

Якщо ви оновлюєтесь з Apache 2.2 на 2.4, конфігурація контролю доступу змінилась. Це частий джерело помилок "403 Forbidden" після оновлення.

Apache за Reverse Proxy

Якщо Apache стоїть за балансувальником або проксі, клієнт з'єднується з проксі по HTTPS, а проксі передає запит на Apache по HTTP. Звичайний редирект створить петлю.

Спочатку увімкніть необхідні модулі:

a2enmod proxy proxy_http headers rewrite ssl
systemctl reload apache2

Конфігурація для reverse proxy:

<VirtualHost *:80>
    ServerName example.com
    ProxyPreserveHost On
    ProxyRequests Off
    ProxyPass        / http://127.0.0.1:8080/
    ProxyPassReverse / http://127.0.0.1:8080/
    RequestHeader set X-Forwarded-Proto "http"
</VirtualHost>
<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile /etc/ssl/cert.pem
    SSLCertificateKeyFile /etc/ssl/key.pem
    ProxyPreserveHost On
    ProxyRequests Off
    ProxyPass        / http://127.0.0.1:8080/
    ProxyPassReverse / http://127.0.0.1:8080/
    RequestHeader set X-Forwarded-Proto "https"
</VirtualHost>

Backend додаток перевіряє заголовок X-Forwarded-Proto і редиректить тільки якщо там не "https":

RewriteCond %{HTTP:X-Forwarded-Proto} !=https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Nginx: оптимальна конфігурація

Nginx — найпопулярніший веб-сервер для високонавантажених проєктів. Редирект тут налаштовується простіше, ніж в Apache.

return 301 vs rewrite: що краще?

Використовуйте return 301 — це рекомендований варіант. Він простіше, швидше обробляється (без regex), одразу формує відповідь і не проходить інші фази обробки.

rewrite потрібен тільки якщо вам треба складна логіка з регулярними виразами.

Базовий редирект

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

HTTPS з HTTP/2

HTTP/2 стабільний і рекомендований завжди, якщо є HTTPS. Дає помітне прискорення завантаження через мультиплексування запитів.

server {
    listen 443 ssl http2;
    server_name example.com;
    ssl_certificate     /etc/ssl/cert.pem;
    ssl_certificate_key /etc/ssl/key.pem;
    
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;  # для TLS 1.3
    
    keepalive_timeout 65;
    keepalive_requests 1000;
    
    gzip on;
    gzip_types text/plain text/css application/json application/javascript;
    
    root /var/www/html;
}

HTTP/3 (QUIC) — експериментально

HTTP/3 у Nginx досі експериментальний. Використовуйте тільки якщо готові до тестування і можливих проблем.

server {
    listen 443 ssl http2;
    listen 443 quic reuseport;
    ssl_protocols TLSv1.3;
    ssl_certificate     /etc/ssl/cert.pem;
    ssl_certificate_key /etc/ssl/key.pem;
    add_header Alt-Svc 'h3=":443"; ma=86400';
}

Заголовок Alt-Svc повідомляє браузеру, що доступний HTTP/3. Браузер спробує наступне з'єднання через QUIC.

Nginx з Upstream (балансування)

Якщо Nginx працює як балансувальник перед декількома backend-серверами:

upstream backend {
    server 127.0.0.1:8080;
    keepalive 32;
}
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}
server {
    listen 443 ssl http2;
    server_name example.com;
    ssl_certificate     /etc/ssl/cert.pem;
    ssl_certificate_key /etc/ssl/key.pem;
    location / {
        proxy_pass http://backend;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For   $remote_addr;
    }
}

Зверніть увагу на X-Forwarded-Proto — backend отримує інформацію про оригінальний протокол і може правильно формувати посилання.

Cloudflare і CDN: редирект на edge

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

Рекомендована архітектура

Client
  ↓
Cloudflare (redirects, edge logic)
  ↓
Nginx (origin, app logic)
  ↓
Upstream / Backend

Переваги редиректу на CDN: швидше (відповідь з найближчого edge-сервера), менше навантаження на origin.

Як уникнути redirect loops

Найчастіша проблема: CDN редиректить на HTTPS, а сервер теж редиректить, бо бачить HTTP-з'єднання від CDN. Результат — безкінечна петля.

Рішення: встановіть SSL mode "Full (strict)" у Cloudflare. Це означає:

• Cloudflare з'єднується з вашим сервером по HTTPS
• Перевіряє валідність сертифікату на сервері
• Ваш сервер бачить HTTPS-з'єднання і не редиректить

Режим "Flexible" (Cloudflare→сервер по HTTP) — це компроміс для серверів без сертифікату. Якщо у вас є сертифікат — використовуйте Full (strict).

Page Rules для HTTPS

В Cloudflare можна налаштувати Page Rules для автоматичного редиректу:

Перші два правила переводять HTTP на HTTPS. Третє — канонізує www на версію без www (або навпаки, залежно від вашого вибору).

HSTS: примусовий HTTPS на рівні браузера

HSTS (HTTP Strict Transport Security) — це заголовок, який каже браузеру: "Ніколи не з'єднуйся з цим доменом по HTTP. Навіть якщо користувач введе http:// — використовуй https://".

Як налаштувати

Strict-Transport-Security: max-age=31536000; includeSubDomains

max-age=31536000 — браузер запам'ятає цю політику на рік (у секундах).

includeSubDomains — політика поширюється на всі піддомени.

Для Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

HSTS Preload — обережно!

HSTS Preload — це включення домену в список, вбудований у браузери. Браузер навіть при першому візиті буде використовувати HTTPS, без необхідності спочатку отримати заголовок.

Ризики HSTS

• Повна недоступність при TLS-проблемі: якщо сертифікат протухне чи щось зламається — сайт стане недоступним. Браузер не дасть користувачу обійти попередження.
• Неможливість швидкого rollback: після видалення з preload-списку пройдуть місяці, поки всі браузери оновляться.
• includeSubDomains ламає піддомени: якщо у вас є dev.example.com без HTTPS — він стане недоступним.
• Direct IP access неможливий: якщо хтось звертається до сервера по IP — HSTS не спрацює, бо прив'язаний до домену. Але якщо раніше домен працював з HSTS, браузер блокуватиме HTTP навіть при спробі обійти.

Почніть з короткого max-age (86400 — один день). Переконайтесь, що все працює. Поступово збільшуйте до року.

Інструменти для перевірки

Після налаштування редиректів обов'язково перевірте, що все працює правильно. Ось інструменти, які ми рекомендуємо.

Безпека та HTTPS/TLS

Перевірка ланцюжка редиректів

Найпростіший спосіб — curl з терміналу:

curl -IL https://example.com | grep -Ei 'HTTP/|Location|Server|cf-'

Прапорець -I показує тільки заголовки, -L слідує за редиректами. Ви побачите весь ланцюжок: HTTP/1.1 301, Location, потім HTTP/2 200 на фінальній сторінці.

Performance і CDN

На що звернути увагу

• Один редирект, не більше. http:// → https:// напряму.
• Правильний код відповіді: 301 для постійного редиректу.
• Канонічна версія: або з www, або без — але одна.
• HSTS заголовок присутній на HTTPS-версії.
• Сертифікат валідний і ланцюжок повний.

Типові помилки та як їх уникнути

Redirect Loop (ERR_TOO_MANY_REDIRECTS)

Браузер показує помилку "This page isn't working" з кодом ERR_TOO_MANY_REDIRECTS.

Причини:

• CDN редиректить на HTTPS, сервер теж редиректить (бо бачить HTTP від CDN)
• Подвійний редирект у .htaccess і VirtualHost одночасно
• WordPress з плагіном HTTPS + серверний редирект
• Неправильні правила для www/non-www

Діагностика: curl -IL http://example.com — подивіться, скільки редиректів і куди.

Рішення: редирект має бути в одному місці. Якщо CDN — тільки на CDN. Якщо сервер — тільки на сервері. При використанні Cloudflare — SSL mode Full (strict).

Mixed Content

Сторінка завантажується по HTTPS, але частина ресурсів (картинки, скрипти, стилі) — по HTTP. Браузер блокує або показує попередження.

Діагностика:

• Chrome DevTools → Console — шукайте "Mixed Content" warnings
• Chrome DevTools → Security tab — покаже небезпечні ресурси

Рішення:

• Знайдіть усі http:// посилання в коді і замініть на https:// або //
• Перевірте базу даних (WordPress часто зберігає абсолютні URL)
• Додайте CSP заголовок: Content-Security-Policy: upgrade-insecure-requests — браузер автоматично замінить http на https

Сертифікат не покриває www

Сертифікат видано для example.com, але не для www.example.com. При заході на www — попередження браузера.

Рішення: отримайте сертифікат для обох варіантів. Let's Encrypt дозволяє включити кілька доменів: certbot -d example.com -d www.example.com

Редирект без збереження шляху

http://example.com/about → https://example.com/ (без /about)

Користувач губить контекст, пошукові системи бачать 404 для старих URL.

Рішення: переконайтесь, що редирект зберігає URI:

# Nginx — правильно
return 301 https://example.com$request_uri;
# Nginx — неправильно (втрачає шлях)
return 301 https://example.com;

SSL-сертифікати: Let's Encrypt і Wildcard

Let's Encrypt — автоматизація

Let's Encrypt — безкоштовні сертифікати з автоматичним оновленням. Це стандарт для більшості сайтів.

Сертифікати видаються на 90 днів, тому автоматичне оновлення критично важливе. Certbot зазвичай налаштовує cron job автоматично:

# Перевірити, чи налаштовано автооновлення
systemctl list-timers | grep certbot
# Або перевірити cron
cat /etc/cron.d/certbot

Тестовий запуск оновлення (без реального оновлення):

certbot renew --dry-run

Wildcard сертифікати

Wildcard сертифікат (*.example.com) покриває всі піддомени одного рівня: blog.example.com, shop.example.com, api.example.com.

Коли рекомендуємо:

• Багато піддоменів, які часто змінюються
• Динамічно створювані піддомени (user1.example.com, user2.example.com)
• Спрощення управління — один сертифікат замість десятків

Важливо: wildcard покриває тільки один рівень. *.example.com покриває blog.example.com, але НЕ покриває dev.blog.example.com.

Let's Encrypt видає wildcard сертифікати через DNS challenge:

certbot certonly --manual --preferred-challenges dns \
  -d example.com -d *.example.com

Для автоматизації DNS challenge потрібен плагін для вашого DNS-провайдера (Cloudflare, Route53, DigitalOcean тощо).

Чеклист: 301 редирект HTTP→HTTPS

Перед запуском пройдіться по цьому списку:

Підготовка

• ☐ SSL-сертифікат встановлено і валідний
• ☐ Сертифікат покриває всі потрібні домени (основний + www)
• ☐ Автоматичне оновлення сертифікату налаштовано
• ☐ Визначено канонічну версію (з www або без)

Налаштування редиректу

• ☐ Редирект тільки в одному місці (сервер АБО CDN, не обидва)
• ☐ Використовується код 301 (не 302)
• ☐ Зберігається повний шлях ($request_uri)
• ☐ Один редирект, не ланцюжок

Якщо використовуєте CDN

• ☐ SSL mode Full (strict) у Cloudflare
• ☐ Page Rules для HTTPS налаштовано
• ☐ Серверний редирект вимкнено (щоб уникнути петлі)

Після запуску

• ☐ Перевірено curl -IL — один 301, потім 200
• ☐ SSL Labs показує A або вище
• ☐ Немає Mixed Content у консолі браузера
• ☐ HSTS заголовок присутній
• ☐ Внутрішні посилання оновлено на https://
• ☐ Sitemap оновлено з https:// URL
• ☐ Google Search Console — додано HTTPS-версію

Часті запитання

Чи вплине редирект на SEO?

Правильний 301 редирект передає ~90-99% ваги посилань. Google офіційно підтверджує, що HTTPS — фактор ранжування. Короткочасне падіння позицій можливе (поки Google переіндексує), але в довгостроковій перспективі HTTPS краще для SEO.

Чи потрібен платний сертифікат?

Для більшості сайтів — ні. Let's Encrypt забезпечує такий самий рівень шифрування. Платні сертифікати (OV, EV) дають розширену валідацію компанії, але це важливо тільки для банків, фінансових установ та великих e-commerce.

Що робити зі старими посиланнями?

301 редирект автоматично перенаправляє старі HTTP-посилання. Але краще оновити: внутрішні посилання на сайті, посилання в соцмережах та профілях, Google Search Console та Analytics. Sitemap має містити тільки https:// URL.

Як перевірити, чи працює HSTS?

Відкрийте DevTools → Network → виберіть будь-який запит → Response Headers. Шукайте Strict-Transport-Security. Або перевірте на securityheaders.com — він покаже оцінку і всі заголовки.

Редирект працює, але сайт повільний. Чому?

Можливі причини: довгий ланцюжок редиректів (перевірте curl -IL), повільний TLS handshake (застарілі налаштування), сервер далеко від користувачів (потрібен CDN). Також перевірте OCSP stapling — без нього браузер робить додатковий запит для перевірки сертифікату.

Чи можна відкатити HSTS?

Так, але повільно. Встановіть max-age=0 і почекайте, поки старий термін закінчиться у кешах браузерів. Якщо використовували HSTS Preload — процес займе місяці. Тому починайте з короткого max-age.

Залишились питання? Напишіть у чат — допоможемо з налаштуванням.