ERR_TOO_MANY_REDIRECTS היא שגיאה שמופיעה כשהאתר נכנס ללולאת הפניות: כתובת א' מפנה לכתובת ב', וכתובת ב' מפנה בחזרה לא' — או לשרשרת שחוזרת לעצמה. אחרי מספר ניסיונות הדפדפן מוותר ומציג "הדף אינו פועל — הפניה מחדש יותר מדי פעמים". כמעט תמיד הסיבה היא שני רכיבים שכל אחד מהם "מתקן" את הכתובת בכיוון אחר: Cloudflare ושרת האתר, תוסף ווורדפרס, או שני כללי הפניה שסותרים זה את זה. החדשות הטובות: זו אחת השגיאות הקלות לאבחון, כי אפשר לראות בדיוק מי מפנה לאן.
איך רואים את הלולאה בעיניים
לפני שמנחשים, כדאי להסתכל על ההפניות עצמן. פקודה אחת מציגה כל קפיצה ואת הכתובת שהיא מפנה אליה:
curl -sIL --max-redirs 8 https://example.co.il/ | grep -iE '^(HTTP|location)'
אם רואים את אותן שתי כתובות מתחלפות — למשל http:// ו-https://, או עם www ובלי — מצאתם את הלולאה. בכרום אפשר לראות את אותו מידע בלשונית Network בכלי המפתחים, עם סימון "Preserve log".
האשם מספר אחת: מצב ההצפנה Flexible ב-Cloudflare
זו הסיבה הנפוצה ביותר באתרים שמאחורי Cloudflare, והיא מתועדת היטב בעמוד של Cloudflare על השגיאה. במצב Flexible, הגולש מתחבר ל-Cloudflare ב-HTTPS, אבל Cloudflare פונה לשרת ב-HTTP רגיל. אם השרת (או וורדפרס) מוגדר להפנות כל בקשת HTTP ל-HTTPS, הוא מפנה — Cloudflare שוב פונה ב-HTTP — והלולאה נסגרת.
לפי Cloudflare, הפתרון הוא להעביר את מצב ההצפנה ל-Full או Full (strict), מה שדורש תעודה בשרת, או להסיר את ההפניה מהשרת ולאכוף HTTPS בקצה של Cloudflare. הפתרון הנכון לאתר עסקי הוא Full (strict), שגם מצפין את החיבור לשרת וגם בודק את התעודה. על ההבדלים בין המצבים כתבתי במאמר Cloudflare מה זה.
שאר הסיבות שכדאי להכיר
| מצב | מה קורה | התיקון |
|---|---|---|
| Full / Full (strict) | Cloudflare פונה ב-HTTPS, והשרת מפנה חזרה ל-HTTP | להסיר את ההפניה ל-HTTP בשרת |
| Always Use HTTPS | Cloudflare מפנה ל-HTTPS, השרת מחזיר ל-HTTP | להסיר את ההפניה בשרת, או לכבות את ההגדרה |
| HSTS | הדפדפן מחויב ל-HTTPS, והשרת מפנה ל-HTTP | להסיר את ההפניה בשרת ולוודא שההצפנה לא כבויה |
| כללי הפניה סותרים | כלל אחד מפנה ל-www, כלל אחר מסיר אותו | להשאיר כלל אחד, במקום אחד |
הטבלה מבוססת על המקרים שמפורטים בתיעוד של Cloudflare. העיקרון המשותף: החלטה על הכתובת הקנונית צריכה להתקבל במקום אחד — או ב-Cloudflare, או בשרת — ולא בשניהם בכיוונים שונים.
לולאות שמקורן בוורדפרס
כתובת האתר בהגדרות לא תואמת
בוורדפרס יש שתי הגדרות כתובת (כתובת וורדפרס וכתובת האתר). אם הן מוגדרות ל-http בזמן שהשרת מפנה ל-https, או עם www בזמן שכלל אחר מסיר אותו — וורדפרס ינסה "לתקן" את הכתובת, והשרת יחזיר אותה. זה קורה הרבה אחרי העברת אתר או מעבר ל-HTTPS. התיקון: לוודא ששתי ההגדרות זהות לכתובת הסופית, כולל https והחלטה עקבית לגבי www.
תוספי הפניות ואבטחה
תוסף שמנהל הפניות, תוסף SSL שמכריח HTTPS, ותוסף אבטחה שמפנה את דף ההתחברות — כל אחד יכול להוסיף שכבת הפניות משלו. אם הלולאה התחילה אחרי התקנה או עדכון של תוסף, כבו אותו (גם על ידי שינוי שם התיקייה שלו, אם אין גישה לממשק) ובדקו שוב.
מטמון של הפניה ישנה
הפניות 301 נשמרות במטמון הדפדפן, ולפעמים גם בשכבות מטמון של האתר. אחרי שתיקנתם, ייתכן שתמשיכו לראות את הלולאה. נקו את העוגיות והמטמון לאתר הספציפי, נקו את מטמון האתר ואת מטמון Cloudflare, ובדקו שוב בחלון גלישה בסתר. על שכבות המטמון השונות הרחבתי במאמר מטמון באתר.
כשהלולאה היא רק בעמוד אחד
אם רק עמוד מסוים נתקע, הסיבה כמעט תמיד בכלל הפניה ספציפי: הפניה מ-/page ל-/page/ שמתנגשת עם כלל שמסיר סלאש, או הפניה ישנה שמישהו יצר בטעות מהכתובת אל עצמה. בדקו את רשימת ההפניות בתוסף או בשרת. איך בונים מפת הפניות בלי שרשראות ולולאות, פירטתי במאמר הפניה 301.
שאלות נפוצות
אצלי זה עובד ואצל אחרים לא — למה?
כנראה מטמון: הדפדפן שלכם שמר הפניה ישנה (או שעוגיית התחברות משנה את ההתנהגות). בדקו בחלון גלישה בסתר ומרשת אחרת.
האם לולאת הפניות פוגעת בגוגל?
כן. עמוד שנתקע בלולאה לא נגיש לגולשים וגם לא ל-Googlebot, ולכן לא ייסרק ולא יופיע בתוצאות. אחרי תיקון כדאי לבקש סריקה מחדש ב-Search Console.
להחזיר את Cloudflare ל-Flexible "רק בינתיים"?
לא. Flexible משאיר את החיבור לשרת לא מוצפן, וזה בדיוק המצב שגורם ללולאה. עדיף להתקין תעודה בשרת ולעבור ל-Full (strict).
מאמרים קשורים: שגיאות תעודת SSL: ERR_CERT_AUTHORITY_INVALID ומה עוד עוצר גולשים.
מעבר ל-HTTPS, העברת אתר ושינוי מבנה כתובות הם הרגעים שבהם לולאות הפניה נולדות. אני מטפל בהם כחלק משדרוג והעברת אתרים — ואם האתר שלכם תקוע בלולאה עכשיו, כתבו לי.
אהבתם את המאמר?
