Chrome brauzerida «Bu sahifa ishlamayapti, sayt sizni juda ko'p marta yo'naltirdi» degan xabar va ERR_TOO_MANY_REDIRECTS kodi chiqsa, bu saytning yo'naltirish qoidalari bir-biriga zid ekanini bildiradi. Masalan, bir qoida brauzerni HTTP dan HTTPS ga yuboradi, boshqasi esa uni yana HTTP ga qaytaradi va bu aylanish to'xtamaydi. Brauzer bir necha o'n marta urinib ko'rgach, jarayonni to'xtatadi va xato ko'rsatadi. Firefox xuddi shu holatni «sahifa to'g'ri yo'naltirilmayapti» deb ataydi. Yaxshi xabar shundaki, bunday muammoning sababi deyarli har doim sozlamalarda bo'ladi va uni aniq ko'rish mumkin.
Yo'naltirish zanjirini o'z ko'zingiz bilan ko'ring
Taxmin qilishdan oldin, server aynan qaysi manzillarga yo'naltirayotganini ko'rib oling. Buning uchun curl buyrug'i eng qulay vosita: u har bir javobning sarlavhasini va keyingi manzilni chiqaradi. Kompyuteringizda yoki serverda quyidagini ishga tushiring:
curl -sIL --max-redirs 10 http://example.uz | grep -iE "^HTTP|^location"Natijada siz 301 yoki 302 javoblari va Location sarlavhalarini ko'rasiz. Agar ro'yxatda bir xil ikki manzil navbatma-navbat takrorlansa, masalan https://example.uz/ va http://example.uz/, demak aylanish aynan shu ikki qoida o'rtasida. Agar www.example.uz va example.uz almashinib tursa, muammo www qoidalarida. Bu bitta buyruq ko'pincha sababni darhol ko'rsatadi.
HTTPS yo'naltirishi va proksi ziddiyati
Eng ko'p uchraydigan holat saytni Cloudflare kabi proksi xizmati orqali ishlatganda yuzaga keladi. Agar proksida SSL rejimi «Flexible» qilib qo'yilgan bo'lsa, tashrif buyuruvchi HTTPS orqali proksiga ulanadi, proksi esa serverga oddiy HTTP orqali murojaat qiladi. Server esa HTTP so'rovni ko'rib, «HTTPS ga o'ting» deb javob beradi. Proksi bu javobni brauzerga uzatadi, brauzer yana HTTPS orqali keladi va aylanish boshlanadi. Bunday holda yechim proksidagi rejimni «Full» yoki «Full (strict)» ga o'zgartirishdir, chunki serverda haqiqiy SSL sertifikati bo'lishi kerak. Hostingda bepul Let's Encrypt sertifikati bo'lsa, «Full (strict)» to'g'ri tanlov hisoblanadi.
Agar proksini o'chirib bo'lmasa, server qoidasi so'rov aslida HTTPS orqali kelganini X-Forwarded-Proto sarlavhasidan aniqlashi mumkin. Ammo bu faqat ishonchli proksi ortida ishlaganda xavfsiz yondashuv hisoblanadi.
.htaccess dagi takroriy yoki zid qoidalar
Ba'zan sayt egasi .htaccess ga HTTPS qoidasini qo'shadi, keyin xuddi shu ishni qiluvchi plagin o'rnatadi yoki panelda ham yo'naltirishni yoqadi. Qoidalar bir-biriga mos kelmasa, masalan biri www ga, boshqasi www siz manzilga yuborsa, cheksiz aylanish paydo bo'ladi. HTTPS va asosiy domenni bitta joyda, bitta qoida bilan belgilash eng ishonchli yo'l. Quyidagi misol barcha so'rovlarni https://example.uz ga, ya'ni www siz HTTPS manzilga yo'naltiradi:
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.uz%{REQUEST_URI} [L,R=301]ISPmanager panelida sayt sozlamalarida ham HTTP dan HTTPS ga yo'naltirish katagi bo'lishi mumkin. Agar u yoqilgan bo'lsa, .htaccess dagi HTTPS qatorini olib tashlash va faqat www bo'yicha qoidani qoldirish mumkin: ikki joyda bir xil vazifani bajarish xatoga yo'l ochadi.
Bu qoidani boshqa barcha qoidalardan oldin, fayl boshiga qo'ying va xuddi shu vazifani bajaradigan boshqa qatorlarni olib tashlang. Agar saytingiz www bilan ishlashi kerak bo'lsa, shartni teskarisiga o'zgartiring, lekin ikkala variantni bir vaqtda qoldirmang.
WordPress manzil sozlamalari
WordPress ma'lumotlar bazasida ikki muhim qiymat saqlanadi: siteurl va home. Agar ularda http://www.example.uz yozilgan bo'lsa, server esa hamma narsani https://example.uz ga yo'naltirsa, WordPress o'z navbatida brauzerni yana «o'z» manziliga qaytaradi. Natijada xuddi shu cheksiz aylanish hosil bo'ladi. Admin panelga kira olmasangiz, qiymatlarni wp-config.php orqali majburan belgilash mumkin:
define('WP_HOME', 'https://example.uz');
define('WP_SITEURL', 'https://example.uz');SSH va WP-CLI mavjud bo'lsa, bazadagi qiymatlarni to'g'ridan-to'g'ri tekshirish va o'zgartirish ham mumkin:
wp option get siteurl
wp option get home
wp option update siteurl 'https://example.uz'
wp option update home 'https://example.uz'Shuningdek, HTTPS ga majburlovchi yoki yo'naltirishlarni boshqaruvchi plaginlarni tekshiring. Plagin papkasini vaqtincha qayta nomlash ularning ta'sirini tez aniqlashga yordam beradi.
Real vaziyatdan misol
Toshkentdagi xususiy maktab sayti yangi domenga ko'chirilgandan keyin bosh sahifa ochilmay qolgan. curl buyrug'i ko'rsatdiki, server http so'rovni https ga yuboradi, keyin WordPress uni eski domenga, eski domen esa yana yangi domenga qaytaradi. Sabab bazada qolib ketgan eski home qiymati edi. Qiymat yangi HTTPS manzilga o'zgartirilgach va kesh tozalangach, sayt darhol ochildi. Bu misol shuni ko'rsatadiki, ko'chirishdan keyin yo'naltirish muammolarining katta qismi bazadagi eski manzillardan kelib chiqadi.
Kesh va cookie fayllarini ham tozalang
Brauzer 301 yo'naltirishlarni uzoq vaqt eslab qoladi. Shuning uchun serverdagi sozlama tuzatilgandan keyin ham sizda xato davom etishi mumkin, boshqalarda esa sayt ishlaydi. Tekshirishni yashirin (inkognito) oynada yoki curl bilan bajaring, kerak bo'lsa brauzer keshi va sayt cookie fayllarini o'chiring. Sahifa kesh plaginlari ham eski yo'naltirishni saqlab qolishi mumkin, ularni tozalashni unutmang.
Agar barcha sozlamalar to'g'ri ko'rinsa-yu, aylanish davom etsa, sayt.uz kabinetidagi texnik yordamga curl natijasini qo'shib murojaat qiling: zanjir ko'rinib turgani muammoni tezroq hal qilishga yordam beradi.