301 přesměrování HTTP na HTTPS: kompletní průvodce pro Apache, Nginx, Cloudflare

⏱️ Doba čtení: ~11 minut | 📅 Aktualizováno: 30. prosince 2025

HTTP v roce 2026 — není to jen zastaralé. Je to nebezpečné

Prohlížeče označují HTTP stránky jako "Nezabezpečené". Google je řadí níže ve vyhledávání. Uživatelé vidí varování a zavírají záložku. A pokud má váš web formulář — heslo, email, číslo karty — všechna tato data letí po síti jako prostý text.

SSL/TLS certifikáty jsou dnes zdarma (díky Let's Encrypt). Není důvod zůstávat na HTTP. Ale instalace certifikátu je jen polovina práce. Druhá polovina je správně nastavit přesměrování, aby veškerý provoz automaticky procházel přes HTTPS.

Zdá se to jednoduché, ne? Přidáte jeden řádek do konfigurace a je hotovo. Ale v praxi právě zde vznikají problémy: nekonečné smyčky přesměrování, mixed content, ztráta pozic ve vyhledávání kvůli nesprávné kanonizaci, problémy s CDN.

Tento článek pokrývá, jak udělat vše správně napoprvé. Konkrétní konfigurace pro Apache, Nginx, Cloudflare. Co se může pokazit a jak to opravit.

301 přesměrování: co to je a proč právě 301

HTTP přesměrování je instrukce pro prohlížeč: "Stránka zde není, jdi na tuto adresu". Kód 301 znamená "Moved Permanently" — trvale přesunuto.

Proč 301, ne 302 nebo 307?

301 (Moved Permanently) — trvalé přesměrování. Vyhledávače předávají váhu odkazů na novou adresu. Prohlížeče cachují přesměrování, takže opakované požadavky jdou přímo na HTTPS.

302 (Found / Temporary Redirect) — dočasné. Vyhledávače nepředávají váhu, protože to považují za dočasné. Špatná volba pro HTTP→HTTPS.

307 (Temporary Redirect) — také dočasné, ale zachovává metodu požadavku (POST zůstává POST). Nevhodné pro běžné přesměrování na HTTPS.

308 (Permanent Redirect) — jako 301, ale zachovává metodu. Lze použít, ale 301 je kompatibilnější se staršími prohlížeči.

Řetězce přesměrování: proč jsou špatné

Častá chyba: http://example.com → http://www.example.com → https://www.example.com → https://example.com. Čtyři skoky místo jednoho.

Každé přesměrování přidává 50-200ms zpoždění. Pro mobilní uživatele na pomalém připojení je to kritické. Google to počítá jako součást doby načítání.

Správný přístup: jedno přesměrování přímo na finální adresu. Rozhodněte, která verze je kanonická (s www nebo bez), a přesměrujte vše tam.

Apache: správná konfigurace

Pro Apache je doporučená metoda přes konfiguraci VirtualHost, ne .htaccess. VirtualHost je rychlejší, protože .htaccess se znovu čte při každém požadavku.

Základní přesměrování přes 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>

Rozdíly mezi Apache 2.2 a 2.4

Pokud upgradujete z Apache 2.2 na 2.4, konfigurace řízení přístupu se změnila. To je častý zdroj chyb "403 Forbidden" po upgradu.

Apache za Reverse Proxy

Pokud Apache stojí za load balancerem nebo proxy, klient se připojuje k proxy přes HTTPS a proxy předává požadavek na Apache přes HTTP. Běžné přesměrování vytvoří smyčku.

Nejprve povolte potřebné moduly:

a2enmod proxy proxy_http headers rewrite ssl
systemctl reload apache2

Konfigurace pro 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 aplikace kontroluje hlavičku X-Forwarded-Proto a přesměrovává pouze pokud tam není "https":

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

Nginx: optimální konfigurace

Nginx je nejpopulárnější webový server pro vysoce zatížené projekty. Nastavení přesměrování je zde jednodušší než v Apache.

return 301 vs rewrite: co je lepší?

Použijte return 301 — to je doporučená varianta. Je jednodušší, zpracovává se rychleji (bez regex), okamžitě formuje odpověď a neprochází dalšími fázemi zpracování.

rewrite je potřeba pouze pokud vyžadujete složitou logiku s regulárními výrazy.

Základní přesměrování

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

HTTPS s HTTP/2

HTTP/2 je stabilní a doporučený vždy, když je povolen HTTPS. Poskytuje znatelné zrychlení načítání díky multiplexování požadavků.

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;  # pro 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) — experimentální

HTTP/3 v Nginx je stále experimentální. Používejte pouze pokud jste připraveni na testování a možné problémy.

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';
}

Hlavička Alt-Svc říká prohlížeči, že je k dispozici HTTP/3. Prohlížeč zkusí další připojení přes QUIC.

Nginx s Upstream (load balancing)

Pokud Nginx funguje jako load balancer před několika backend servery:

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;
    }
}

Všimněte si X-Forwarded-Proto — backend dostává informaci o původním protokolu a může správně formovat odkazy.

Cloudflare a CDN: přesměrování na edge

Pokud používáte Cloudflare nebo jiné CDN, můžete přesměrovávat na úrovni CDN — ještě předtím, než požadavek dorazí na váš server.

Doporučená architektura

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

Výhody přesměrování na CDN: rychlejší (odpověď z nejbližšího edge serveru), menší zatížení originu.

Jak se vyhnout redirect loops

Nejčastější problém: CDN přesměrovává na HTTPS a server také přesměrovává, protože vidí HTTP připojení od CDN. Výsledek — nekonečná smyčka.

Řešení: nastavte SSL mode na "Full (strict)" v Cloudflare. To znamená:

• Cloudflare se připojuje k vašemu serveru přes HTTPS
• Ověřuje platnost certifikátu na serveru
• Váš server vidí HTTPS připojení a nepřesměrovává

Režim "Flexible" (Cloudflare→server přes HTTP) je kompromis pro servery bez certifikátu. Pokud máte certifikát — použijte Full (strict).

Page Rules pro HTTPS

V Cloudflare můžete nastavit Page Rules pro automatické přesměrování:

První dvě pravidla převádějí HTTP na HTTPS. Třetí kanonizuje www na verzi bez www (nebo naopak, podle vaší volby).

HSTS: vynucené HTTPS na úrovni prohlížeče

HSTS (HTTP Strict Transport Security) je hlavička, která říká prohlížeči: "Nikdy se nepřipojuj k této doméně přes HTTP. I když uživatel zadá http:// — použij https://".

Jak nastavit

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

max-age=31536000 — prohlížeč si zapamatuje tuto politiku na jeden rok (v sekundách).

includeSubDomains — politika se vztahuje na všechny subdomény.

Pro Nginx:

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

HSTS Preload — opatrně!

HSTS Preload znamená přidání vaší domény do seznamu zabudovaného v prohlížečích. Prohlížeč bude používat HTTPS i při první návštěvě, bez nutnosti nejprve získat hlavičku.

Rizika HSTS

• Úplná nedostupnost při TLS problémech: pokud certifikát vyprší nebo se něco pokazí — web se stane nedostupným. Prohlížeč nedovolí uživatelům obejít varování.
• Žádný rychlý rollback: po odstranění z preload seznamu trvá měsíce, než se všechny prohlížeče aktualizují.
• includeSubDomains rozbíjí subdomény: pokud máte dev.example.com bez HTTPS — stane se nedostupným.
• Přímý IP přístup nemožný: pokud někdo přistupuje k serveru přes IP — HSTS nefunguje, protože je vázán na doménu. Ale pokud doména dříve fungovala s HSTS, prohlížeč bude blokovat HTTP i při pokusu o obejití.

Začněte s krátkým max-age (86400 — jeden den). Ujistěte se, že vše funguje. Postupně zvyšujte na jeden rok.

Nástroje pro ověření

Po konfiguraci přesměrování nezapomeňte ověřit, že vše funguje správně. Zde jsou nástroje, které doporučujeme.

Bezpečnost a HTTPS/TLS

Kontrola řetězce přesměrování

Nejjednodušší způsob — curl z terminálu:

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

Přepínač -I zobrazuje pouze hlavičky, -L následuje přesměrování. Uvidíte celý řetězec: HTTP/1.1 301, Location, pak HTTP/2 200 na finální stránce.

Performance a CDN

Na co se zaměřit

• Jedno přesměrování, ne více. http:// → https:// přímo.
• Správný kód odpovědi: 301 pro trvalé přesměrování.
• Kanonická verze: buď s www nebo bez — ale jedna.
• HSTS hlavička přítomna na HTTPS verzi.
• Certifikát je platný a řetězec je úplný.

Časté chyby a jak se jim vyhnout

Redirect Loop (ERR_TOO_MANY_REDIRECTS)

Prohlížeč zobrazuje chybu "This page isn't working" s kódem ERR_TOO_MANY_REDIRECTS.

Příčiny:

• CDN přesměrovává na HTTPS, server také přesměrovává (protože vidí HTTP od CDN)
• Dvojité přesměrování v .htaccess a VirtualHost současně
• WordPress s HTTPS pluginem + serverové přesměrování
• Nesprávná pravidla pro www/non-www

Diagnostika: curl -IL http://example.com — podívejte se, kolik je přesměrování a kam.

Řešení: přesměrování by mělo být pouze na jednom místě. Pokud CDN — pouze na CDN. Pokud server — pouze na serveru. Při použití Cloudflare — SSL mode Full (strict).

Mixed Content

Stránka se načítá přes HTTPS, ale některé zdroje (obrázky, skripty, styly) se načítají přes HTTP. Prohlížeč blokuje nebo zobrazuje varování.

Diagnostika:

• Chrome DevTools → Console — hledejte "Mixed Content" varování
• Chrome DevTools → Security tab — ukáže nezabezpečené zdroje

Řešení:

• Najděte všechny http:// odkazy v kódu a nahraďte https:// nebo //
• Zkontrolujte databázi (WordPress často ukládá absolutní URL)
• Přidejte CSP hlavičku: Content-Security-Policy: upgrade-insecure-requests — prohlížeč automaticky nahradí http za https

Certifikát nepokrývá www

Certifikát vydán pro example.com, ale ne pro www.example.com. Při návštěvě www se zobrazí varování prohlížeče.

Řešení: získejte certifikát pro obě varianty. Let's Encrypt umožňuje zahrnout více domén: certbot -d example.com -d www.example.com

Přesměrování bez zachování cesty

http://example.com/about → https://example.com/ (bez /about)

Uživatel ztrácí kontext, vyhledávače vidí 404 pro staré URL.

Řešení: ujistěte se, že přesměrování zachovává URI:

# Nginx — správně
return 301 https://example.com$request_uri;
# Nginx — špatně (ztrácí cestu)
return 301 https://example.com;

SSL certifikáty: Let's Encrypt a Wildcard

Let's Encrypt — automatizace

Let's Encrypt — bezplatné certifikáty s automatickou obnovou. To je standard pro většinu webů.

Certifikáty jsou vydávány na 90 dní, takže automatická obnova je kriticky důležitá. Certbot obvykle nastavuje cron job automaticky:

# Zkontrolujte, zda je nakonfigurována automatická obnova
systemctl list-timers | grep certbot
# Nebo zkontrolujte cron
cat /etc/cron.d/certbot

Testovací spuštění obnovy (bez skutečné obnovy):

certbot renew --dry-run

Wildcard certifikáty

Wildcard certifikát (*.example.com) pokrývá všechny subdomény jedné úrovně: blog.example.com, shop.example.com, api.example.com.

Kdy doporučujeme:

• Mnoho subdomén, které se často mění
• Dynamicky vytvářené subdomény (user1.example.com, user2.example.com)
• Zjednodušená správa — jeden certifikát místo desítek

Důležité: wildcard pokrývá pouze jednu úroveň. *.example.com pokrývá blog.example.com, ale NEPOKRÝVÁ dev.blog.example.com.

Let's Encrypt vydává wildcard certifikáty přes DNS challenge:

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

Pro automatizaci DNS challenge potřebujete plugin pro vašeho DNS poskytovatele (Cloudflare, Route53, DigitalOcean atd.).

Checklist: 301 přesměrování HTTP→HTTPS

Před spuštěním projděte tento seznam:

Příprava

• ☐ SSL certifikát nainstalován a platný
• ☐ Certifikát pokrývá všechny potřebné domény (hlavní + www)
• ☐ Automatická obnova certifikátu nakonfigurována
• ☐ Kanonická verze určena (s www nebo bez)

Konfigurace přesměrování

• ☐ Přesměrování pouze na jednom místě (server NEBO CDN, ne obojí)
• ☐ Používá se kód 301 (ne 302)
• ☐ Celá cesta zachována ($request_uri)
• ☐ Jedno přesměrování, ne řetězec

Pokud používáte CDN

• ☐ SSL mode Full (strict) v Cloudflare
• ☐ Page Rules pro HTTPS nakonfigurovány
• ☐ Serverové přesměrování vypnuto (aby se předešlo smyčce)

Po spuštění

• ☐ Ověřeno curl -IL — jedno 301, pak 200
• ☐ SSL Labs ukazuje A nebo vyšší
• ☐ Žádný Mixed Content v konzoli prohlížeče
• ☐ HSTS hlavička přítomna
• ☐ Interní odkazy aktualizovány na https://
• ☐ Sitemap aktualizována s https:// URL
• ☐ Google Search Console — HTTPS verze přidána

Často kladené otázky

Ovlivní přesměrování SEO?

Správné 301 přesměrování předává ~90-99% váhy odkazů. Google oficiálně potvrzuje, že HTTPS je faktor hodnocení. Krátkodobé poklesy pozic jsou možné (zatímco Google reindexuje), ale z dlouhodobého hlediska je HTTPS pro SEO lepší.

Potřebuji placený certifikát?

Pro většinu webů — ne. Let's Encrypt poskytuje stejnou úroveň šifrování. Placené certifikáty (OV, EV) poskytují rozšířenou validaci společnosti, ale to je důležité pouze pro banky, finanční instituce a velké e-commerce weby.

Co se starými odkazy?

301 přesměrování automaticky přesměrovává staré HTTP odkazy. Ale je lepší aktualizovat: interní odkazy na webu, odkazy na sociálních sítích a v profilech, Google Search Console a Analytics. Sitemap by měla obsahovat pouze https:// URL.

Jak zkontrolovat, zda HSTS funguje?

Otevřete DevTools → Network → vyberte jakýkoli požadavek → Response Headers. Hledejte Strict-Transport-Security. Nebo zkontrolujte na securityheaders.com — ukáže hodnocení a všechny hlavičky.

Přesměrování funguje, ale web je pomalý. Proč?

Možné příčiny: dlouhý řetězec přesměrování (zkontrolujte curl -IL), pomalý TLS handshake (zastaralá nastavení), server daleko od uživatelů (potřeba CDN). Zkontrolujte také OCSP stapling — bez něj prohlížeč dělá extra požadavek pro ověření certifikátu.

Lze HSTS vrátit zpět?

Ano, ale pomalu. Nastavte max-age=0 a počkejte, až starý termín vyprší v cache prohlížečů. Pokud jste použili HSTS Preload — proces bude trvat měsíce. Proto byste měli začít s krátkým max-age.

Máte ještě otázky? Napište nám do chatu — pomůžeme s konfigurací.