HTTPS-átirányítási hurok: miért dob „túl sok átirányítást” hibát az oldalam?
A HTTPS-átirányítási hurok akkor jön létre, amikor a böngésző, a CDN/proxy, a tárhely és a CMS egymásnak ellentmondó protokollállapotot lát. Gyakori példa, hogy a böngésző HTTPS-en csatlakozik a Cloudflare-hez, de a proxy HTTP-n megy tovább az origin szerverhez; az origin ezt HTTP-nek érzékeli és újra HTTPS-re irányít, amit a proxy ismét HTTP-ként küld tovább. Először kapcsold ki a duplikált átirányításokat, majd kövesd végig a láncot HTTP és HTTPS URL-en, közvetlenül az originig. Állítsd be, hogy a proxy megbízhatóan jelezze az eredeti protokollt, és csak egy réteg végezze a kanonikus HTTPS-irányítást. Cloudflare esetén a TLS módot az origin tanúsítványához igazítsd; a Flexible mód nem univerzális megoldás, teljes TLS-hez érvényes origin tanúsítvány kell.
Mit jelent ez az üzletednek?
Súlyosság: magas. A látogató nem éri el az oldalt, a kapcsolatfelvétel leáll, a keresőrobot pedig hibás vagy ismétlődő átirányításokba ütközik.
A hurok gyakran egyszerre zárja ki a látogatót és a Googlebotot a webhelyről. HTTPS-átállás után a főoldal, bejelentkezés vagy űrlap is elérhetetlenné válhat, így a leadvesztés azonnali.
A leggyakoribb okok – és hogyan ismered fel őket
- 1
A CDN és az origin eltérő protokollt érzékel
A proxy HTTPS-t kap, de HTTP-n kommunikál a szerverrel; az alkalmazás ezért minden kérésre újabb HTTPS-átirányítást küld.
Így ellenőrizd: A hurok megszűnik, ha a CDN-t megkerülve közvetlenül az originhez teszteled a kérést?
- 2
Két vagy több réteg is HTTPS-re kényszerít
CDN-szabály, .htaccess, webszerver, CMS-bővítmény és alkalmazáskód egyszerre írja át a protokollt vagy domaint.
Így ellenőrizd: Milyen státusz- és Location fejlécet ad minden egyes ugrás?
- 3
Hibás proxyfejléc vagy CMS alap-URL
Az alkalmazás nem bízik meg az eredeti protokollt jelző fejlécben, vagy a WordPress/webhely URL-je HTTP-t tartalmaz.
Így ellenőrizd: A szerver a megbízható proxy mögött is HTTPS-ként érzékeli az eredeti kérést?
- 4
Nem megfelelő TLS mód vagy origin tanúsítvány
A CDN és a szerver között nincs titkosított, érvényes kapcsolat, ezért a beállítások egymásnak feszülnek.
Így ellenőrizd: A CDN TLS módja megfelel a tárhely origin tanúsítványának és annak érvényességének?
Javítás lépésről lépésre
- 1. lépés
Rögzítsd, mikor és mely URL-en indul a hurok
Jegyezd fel a domainváltozatot, útvonalat, böngészőhibát és a legutóbbi HTTPS/CDN-módosítást. Teszteld a HTTP és HTTPS, www és nem-www változatot külön.
- 2. lépés
Nézd meg az átirányítási láncot
Fejlesztői eszközben vagy biztonságos HTTP-fejlécteszterrel kövesd a Location válaszokat. A láncnak egy végleges HTTPS URL-en kell megállnia, nem oda-vissza váltania.
- 3. lépés
Azonosítsd az átirányító réteget
Ideiglenesen, ellenőrzött módon vizsgáld külön a CDN-szabályt, webkiszolgálót, CMS-t és alkalmazást. Ne kapcsold le egyszerre az egész TLS-védelmet éles oldalon.
- 4. lépés
Egységesítsd a protokoll felismerését
Ha proxy van a szerver előtt, az alkalmazás a csak megbízható proxy által beállított eredeti protokollfejlécet vegye figyelembe. A proxy konfigurációját és a CMS alap-URL-jét igazítsd az éles HTTPS állapothoz.
- 5. lépés
Állíts be egyetlen kanonikus HTTPS-irányítást
Válaszd ki, hogy a www vagy a nem-www domain a végleges, és egyetlen jól meghatározott réteg irányítsa oda a többi változatot. A HTTP minden útvonala a megfelelő HTTPS útvonalra menjen.
- 6. lépés
Tisztítsd a cache-t és teszteld az ügyfélutat
Töröld a CDN- és CMS-cache-t, majd ellenőrizd a főoldalt, szolgáltatásoldalt, kapcsolatfelvételi űrlapot és adminfelületet. Később a Search Console URL-vizsgálatban ellenőrizd, hogy a Google is eléri a végleges URL-t.
Tippek platformonként
Cloudflare
Ellenőrizd az SSL/TLS módot, origin tanúsítványt, Always Use HTTPS és Redirect Rules beállításokat. A Flexible mód HTTP-kapcsolatot használ az origin felé, ezért HTTPS-t erőltető origin mellett hurkot okozhat; ne állíts Full (strict)-et érvényes origin tanúsítvány nélkül.
WordPress
A Beállítások → Általános alatt a WordPress-cím és a webhelycím is a végleges HTTPS URL legyen. Ellenőrizd, hogy bővítmény és .htaccess nem duplázza az átirányítást.
Nginx / Apache / proxy
Ellenőrizd, melyik réteg terminálja a TLS-t, és hogy a proxy fejléceket csak megbízható forrásból fogadod-e. Az origin közvetlen tesztje segít elválasztani a CDN és alkalmazás viselkedését.
Gyakori hibák javítás közben
- A Flexible módot bekapcsolni anélkül, hogy az origin viselkedését ellenőriznéd.
- Az összes HTTPS-átirányítást letiltani és így hagyni.
- Egyszerre több rétegben ugyanazt az átirányítási szabályt fenntartani.
- A főoldalt tesztelni, de a kapcsolatfelvételi és bejelentkezési útvonalat nem.
Mikor kérj segítséget?
Ha CDN, reverse proxy, több szerver vagy WordPress együtt érintett, a hurok forrását az egyes hálózati rétegek válaszából kell beazonosítani. Technikai audit során végigkövetjük a teljes HTTPS-láncot, és ellenőrizzük, hogy minden üzleti URL a végleges címre érkezik.
Gyakori kérdések
A böngésző cookie törlése megjavítja az átirányítási hurkot?
Néha egy hibás cookie okozhat helyi problémát, de a szerveroldali oda-vissza Location láncot nem javítja meg. Próbáld inkognitóban, és ellenőrizd a válaszfejléceket.
Melyik rétegben legyen a HTTPS-átirányítás?
A legfontosabb az egyetlen, egyértelmű felelős réteg és a helyes protokolltovábbítás. Ez lehet CDN vagy webszerver, de az alkalmazás és a proxy beállításai nem mondhatnak ellent egymásnak.
Biztonságos ideiglenesen kikapcsolni az átirányítást?
Diagnosztikához ellenőrzött, rövid idejű változtatás segíthet, de ne hagyd a látogatókat HTTP-n. A végleges állapotban az összes fontos URL-nek HTTPS-en kell működnie.