خطای ERR_TOO_MANY_REDIRECTS زمانی رخ میدهد که درخواست میان نشانیها یا حالت‌های مختلف سایت می‌چرخد و به پاسخ نهایی نمی‌رسد. پیش از تغییر تنظیمات، زنجیرهٔ انتقال را ثبت کنید؛ سپس اختلاف HTTP و HTTPS، نسخهٔ دامنه و تشخیص اتصال امن پشت پراکسی را در همان لایهٔ مسئول اصلاح کنید. پاککردن کوکی تنها یک آزمون تفکیکی است، نه درمان همیشگی حلقهٔ عمومی سایت.
راه‌حل سریع و ایمن
- نشانی دقیق صفحهٔ خراب را در ابزار شبکهٔ مرورگر باز کنید و ثبت درخواست‌ها را هنگام جابه‌جایی حفظ کنید. کد هر پاسخ و مقدار Location را یادداشت کنید تا معلوم شود مسیر بین کدام نشانیها تکرار میشود.
- همان صفحهٔ عمومی را یک بار در پنجرهٔ خصوصی امتحان کنید. اگر فقط نشست قبلی مشکل دارد، اطلاعات همان سایت را پس از ثبت شواهد پاک کنید؛ اگر مهمان هم گیر میکند، روی تنظیمات عمومی و کش تمرکز کنید.
- نسخهٔ مرجع موردنظر را مشخص کنید: HTTPS و دامنه با www یا بدون آن. این تصمیم را با نشانی فعلی وردپرس، قوانین سرور و تنظیمات CDN مقایسه کنید، بدون آنکه همه را هم‌زمان تغییر دهید.
- از قانون یا تنظیمی که قرار است عوض شود نسخهٔ بازگشت بگیرید. در فروشگاه، آزمایش را روی صفحهٔ عمومی انجام دهید و اصلاح مؤثر بر پرداخت یا نشست را ابتدا در محیط آزمایشی بررسی کنید.
- اگر زنجیره میان HTTP و HTTPS می‌چرخد، از میزبان بخواهید محل پایان TLS و شیوهٔ انتقال اطلاعات اتصال امن به وردپرس را تأیید کند. هدر ارسالی از اینترنت را بدون مرز اعتماد، نشانهٔ معتبر HTTPS فرض نکنید.
- اگر حلقه میان دو دامنه یا دو مسیر است، دو قانون متضاد را پیدا کنید و فقط قانون ناسازگار را اصلاح کنید. افزونهٔ امنیتی یا همهٔ قواعد تغییر مسیر را برای آزمون عمومی از کار نیندازید.
- پس از اصلاح، کش پاسخ‌های انتقالِ مسیر درگیر را هدفمند پاک کنید و زنجیره را دوباره ثبت کنید. مقصد نهایی باید محتوای درست بدهد؛ سپس خانه، صفحهٔ داخلی، موبایل و جریان مجاز فروشگاه را جدا بررسی کنید.
ابتدا مشخص کنید کدام درخواست در حلقه است
پیام مرورگر لزوماً به معنای خرابی تمام سایت نیست. شاید سند اصلی سالم باشد اما ورود از یک لینک تبلیغاتی به مسیر قدیمی، زنجیرهٔ معیوبی بسازد. نشانی شروع، نشانی‌هایی که پس از آن دیده می‌شوند و زمان رخداد را ثبت کنید. اگر کاربر می‌گوید فقط با تلفن مشکل دارد، همان لینک و همان روش ورود را بگیرید؛ بازکردن دستی خانه روی رایانه آزمایش معادل آن نیست.
در ابزار شبکه، سند اصلی را از تصویر، درخواست داده و محتوای جاسازی‌شده جدا کنید. گاهی صفحهٔ اصلی یک ابزار بیرونی را بارگذاری میکند و حلقه متعلق به آن دامنه است. در این حالت تغییر نشانی عمومی وردپرس مسئلهٔ بیرونی را حل نمیکند. برعکس، اگر سند اصلی خودش پشت سر هم پاسخ انتقال می‌گیرد، باید مسیر درخواست عمومی را بررسی کرد. تفاوت این دو حالت تعیین میکند مالک اصلاح چه کسی است.
از اولین پاسخ شروع کنید، چون آخرین نشانی روی نوار مرورگر ممکن است فقط یکی از حلقه‌های میانی باشد. اگر زنجیره به HTTP برمی‌گردد اما مرورگر به دلیل سیاست امنیتی دوباره HTTPS را انتخاب میکند، مشاهدهٔ صرف نوار آدرس بخشی از داستان را پنهان میکند. خروجی شبکه را با زمان، حالت مهمان یا واردشده و نوع صفحه نگه دارید. برای گزارش عمومی، کوکی، توکن و نشانی‌های خصوصی را حذف کنید.
فرق حلقهٔ عمومی با بازگشت مکرر صفحهٔ ورود
اگر خانه، مقاله و محصول برای بازدیدکنندهٔ مهمان هم دچار انتقال پیاپی‌اند، مسئله معمولاً در مسیر عمومی درخواست یا قواعد نشانی قرار دارد. اما اگر صفحههای عمومی باز می‌شوند و فقط پس از ورود دوباره به فرم ورود برمیگردید، بررسی نشست، کوکی احراز هویت و مقصد پس از ورود اولویت متفاوتی دارد. برای آن شاخه، مقالهٔ حلقهٔ ریدایرکت ورود وردپرس مسیر اختصاصی‌تری ارائه میکند.
این تفکیک را با دو صفحهٔ عمومی انجام دهید؛ برای تشخیص حلقهٔ عمومی لازم نیست بارها رمز وارد کنید. تکرار ورود ممکن است محدودیت‌های امنیتی را فعال کند و نشانهٔ تازه‌ای بسازد. همچنین اگر پس از چند انتقال به صفحهٔ ناموجود می‌رسید، مسئله لزوماً حلقه نیست؛ زنجیره پایان یافته اما مقصد خراب است. در آن حالت راهنمای ۴۰۴ و پیوندهای یکتا برای بررسی مقصد مناسب‌تر است.
خطای گواهی نیز باید جدا بماند. اگر اتصال امن پیش از دریافت پاسخ HTTP متوقف میشود، هنوز زنجیرهٔ کاربردی کامل در اختیار ندارید. از کاربر نخواهید هشدار گواهی را دور بزند یا دادهٔ ورود را روی اتصال نامطمئن بفرستد. ابتدا مالک دامنه و میزبان باید مشکل اتصال را روشن کنند. پیام‌های نزدیک به هم در مرورگر، الزاماً به یک تنظیم مشترک مربوط نیستند و درمان یکسان نمی‌خواهند.
دسترسی و پشتیبان برای تغییرهای چندلایه
فهرست دسترسی‌ها را براساس مالک قانون تهیه کنید: تنظیمات عمومی وردپرس، افزونهٔ تغییر مسیر، پنل CDN و پیکربندی وب‌سرور ممکن است در اختیار افراد متفاوت باشد. کسی که فقط پیشخوان را می‌بیند نباید نبود قانون را در لایه‌های دیگر قطعی بداند. از هر مسئول بخواهید قواعد مرتبط با همان دامنه و مسیر را گزارش کند. ارسال رمزها برای جمع‌کردن همهٔ دسترسی‌ها در یک گفت‌وگو ضرورتی ندارد.
پیش از تغییر، مقدار فعلی تنظیم، نام قانون و محدودهٔ اثر آن را ثبت کنید. برای قانون CDN، تصویر یا خروجی همان قانون همراه با ترتیب اجرا مفید است؛ برای فایل سرور، نسخهٔ فایل فعال و روش بازگرداندن آن لازم است. پشتیبان کل سایت جای دانستن محل تغییر را نمی‌گیرد. در فروشگاه زنده، بازیابی کامل پایگاه داده برای برگشت یک قانون ممکن است سفارشهای تازه را از بین ببرد و باید از آن پرهیز کرد.
محیط آزمایشی برای قواعد وابسته به پراکسی باید همان مسیر شبکه را تا حد امکان بازنمایی کند. نسخه‌ای که مستقیم به PHP وصل است ممکن است حلقهٔ ناشی از CDN را نشان ندهد. محدودیت آزمایش را بنویسید و آزمون نهایی کنترل‌شده روی مسیر عمومی را فراموش نکنید. اگر هماهنگی میان این مسئولیت‌ها لازم است، پشتیبانی وردپرس می‌تواند نقطهٔ شروع جمع‌آوری شواهد و تعیین اقدام بعدی باشد.
زنجیرهٔ انتقال را پیش از اصلاح بخوانید
برای هر گام، نشانی درخواست، کد وضعیت و مقصد اعلام‌شده را کنار هم بنویسید. لازم نیست جدول پیچیده بسازید؛ چند خط مرتب کافی است. یک حلقه ممکن است بین دو نشانی بچرخد یا پس از چند مقصد به نقطهٔ قبلی برسد. شباهت صفحه‌ها کمکی نمیکند؛ رشتهٔ نشانی، طرح اتصال، دامنه، مسیر و پارامترها را مقایسه کنید. بازگشت به ترکیب قبلی نشانهٔ روشن‌تری از حدس دربارهٔ افزونهٔ مقصر است.
به تغییرهای کوچک توجه کنید: افزوده‌شدن www، حذف اسلش پایانی، تغییر زبان یا حذف یک پارامتر می‌تواند مرز دو قانون باشد. اگر هر بار پارامتر تازه‌ای اضافه میشود، ممکن است حلقه با نشانی یکسان تکرار نشود ولی همچنان پایان نداشته باشد. در این حالت روند تغییر پارامتر را ثبت کنید و نمونهٔ حساس را پاکسازی کنید. انتشار کامل لینک حاوی شناسهٔ نشست برای اثبات حلقه لازم نیست.
هدرهایی که نام افزونه یا نرم‌افزار را نشان می‌دهند فقط سرنخ‌اند. ممکن است واسطه آنها را حذف یا بازنویسی کرده باشد و ممکن است قانون واقعی در لایهٔ قبلی اجرا شده باشد. نتیجهٔ قطعی باید از تطبیق زنجیره با پیکربندی فعال به دست آید. وقتی مالک هر انتقال معلوم شد، کوچک‌ترین تغییر مؤثر را انتخاب کنید؛ این روش از حذف تصادفی چند قانون سالم برای رسیدن به یک نتیجهٔ موقت جلوگیری میکند.
درخواست خواندنی با سقف مشخص برای مشاهدهٔ هدرها
مشاهدهٔ ابزار شبکهٔ مرورگر برای بیشتر مدیران کافی است. اگر امکان استفاده از خط فرمان دارید، یک درخواست عمومی و بدون اطلاعات حساب انتخاب کنید. دستور زیر فقط هدرهای پاسخ نخست را نمایش میدهد و بدنه را کنار می‌گذارد؛ دنبال‌کردن خودکار مقصدها در آن فعال نیست. این محدودیت عمدی است تا همان انتقال نخست، پیش از رسیدن به خطای نهایی، قابل مشاهده باشد.
curl -sS -D - -o /dev/null 'https://example.com/sample-page/'
دامنه و مسیر نمونه را جایگزین کنید و برای گام بعدی، مقصد Location را ابتدا بخوانید. اگر مقصد ناشناس یا خارج از دامنهٔ مورد انتظار بود، آن را با کوکی یا اطلاعات ورود دنبال نکنید. در محیط ویندوز می‌توانید همین مشاهده را در ابزار مرورگر انجام دهید؛ مسیر خروجی مثال برای محیط سازگار نوشته شده و نیازی نیست برای این کار ابزار تازه‌ای نصب کنید.
در گزارش، فقط بخش‌های لازم مانند کد و مقصد پاک‌سازی‌شده را نگه دارید. گزینه‌های اعتماد به گواهی نامعتبر یا ارسال اعتبارنامه برای این تشخیص لازم نیستند. درخواست خواندن یک صفحهٔ عمومی هم نباید با نشانی عملیاتی مثل تأیید سفارش جایگزین شود. اگر پاسخ مرورگر و ابزار متفاوت است، وجود کوکی، کش و تفاوت مسیر شبکه را بررسی کنید؛ هیچ‌کدام را بی‌دلیل شاهد قطعی سلامت یا خرابی همهٔ کاربران ندانید.
درخت تصمیم بر پایهٔ شکل حلقه
اگر نسخهٔ HTTP به HTTPS می‌رود و دوباره به HTTP برمی‌گردد، شاخهٔ تشخیص اتصال امن و تعارض قواعد را جلو بیندازید. اگر طرح اتصال ثابت است اما www اضافه و حذف میشود، مالک نسخهٔ دامنه را پیدا کنید. اگر دامنه و اتصال ثابت‌اند اما دو مسیر جابه‌جا می‌شوند، افزونهٔ ریدایرکت، زبان، اسلش یا قواعد محتوایی محتمل‌تر است. هر شاخه باید با مشاهدهٔ زنجیره انتخاب شود، نه با محبوبیت یک راه‌حل اینترنتی.
اگر فقط مرورگر قدیمی خراب است و پنجرهٔ خصوصی سالم است، ابتدا دادهٔ همان سایت و انتقال ذخیره‌شده را بررسی کنید. اگر همهٔ کاربران مهمان خراب‌اند، پاککردن کوکی تک‌تک کاربران راه‌حل سامانه نیست. اگر فقط کاربران یک منطقه پاسخ متفاوت دارند، کش لبه یا تفاوت مسیر ورود را با مسئول CDN بررسی کنید. این وضعیت به‌خودی‌خود اثبات نمیکند مبدا سالم است، چون بعضی لبه‌ها ممکن است پاسخ قدیمی سالم را نمایش دهند.
پس از انتخاب شاخه، یک فرضیهٔ قابل رد بنویسید. مثلاً «دو لایه نسخهٔ متفاوتی از دامنه را مرجع می‌دانند». سپس از هر لایه شاهد بخواهید و قبل از تغییر، نتیجهٔ مورد انتظار را تعیین کنید: حذف یک گام متضاد و رسیدن به محتوای درست. اگر تغییر این نتیجه را نداد، آن را موفق اعلام نکنید و تنظیم تازه را بدون دلیل روی تنظیمات قبلی انباشته نکنید.
تصمیم روشن دربارهٔ HTTPS و نسخهٔ دامنه
یک قرارداد عمومی انتخاب کنید که با دامنهٔ فعال، گواهی و نیاز سایت سازگار باشد. این قرارداد شامل طرح اتصال و نسخهٔ دامنه است. انتخاب www یا بدون آن به‌تنهایی درمان حلقه نیست؛ مسئله وقتی ایجاد میشود که لایه‌ها دربارهٔ این انتخاب اختلاف داشته باشند. نشانی‌های وردپرس، مقصد قواعد سرور، تنظیمات CDN و خروجی لینک‌ها را با قرارداد موجود مقایسه کنید و ابتدا ناسازگاری را پیدا کنید.
در وردپرس، نشانی محل فایل‌های هسته و نشانی عمومی سایت ممکن است در برخی نصب‌ها یکسان نباشند. تفاوت آنها را بدون شناخت معماری پاک نکنید. همچنین ممکن است مقدار نمایشی از ثابت‌های پیکربندی یا سیاست استقرار تأثیر بگیرد؛ تغییر در پیشخوان وقتی منبع مؤثر جای دیگری است نتیجهٔ مورد انتظار نمی‌دهد. مسئول فنی باید منبع نهایی مقدار را تأیید کند و مشخص کند بعد از استقرار بعدی دوباره بازنویسی میشود یا نه.
جایگزینی سراسری دامنه در پایگاه داده برای درمان اولیه مناسب نیست. چنین کاری می‌تواند داده‌های ساختاریافته و نشانی‌های وابسته را تحت تأثیر قرار دهد و علت تعارض پراکسی را هم حل نکند. اگر مهاجرت دامنه واقعاً لازم است، آن را به عملیات مستقل با پشتیبان، ابزار مناسب و آزمون سازگاری تبدیل کنید. برای این خطا، نخست هم‌راستایی قانون موجود را بررسی کنید و دامنهٔ تغییر را محدود نگه دارید.
TLS در کجا پایان می‌یابد و چرا مهم است
کاربر ممکن است با HTTPS به لبهٔ شبکه وصل شود، اما درخواست از پراکسی تا مبدا با شکل دیگری منتقل شود. اگر وردپرس فقط اتصال مستقیم خود را ببیند و آن را ناامن بداند، ممکن است دوباره کاربر را به HTTPS بفرستد؛ در حالی که کاربر از ابتدا روی همان نشانی امن بوده است. این توضیح یک فرضیهٔ معماری است و باید با مسیر واقعی درخواست و تنظیمات میزبان تطبیق داده شود.
راهنمای رسمی HTTPS در وردپرس به مشکل تشخیص اتصال پشت پراکسی معکوس اشاره میکند. کاربرد این نکته در عیب‌یابی این است که پایان TLS و اطلاعات منتقل‌شده از واسطه باید معلوم باشند. از آن نمی‌توان نتیجه گرفت هر سایت باید قطعه‌کد یکسانی در فایل پیکربندی بگذارد. در بعضی معماری‌ها وب‌سرور یا لایهٔ مدیریت‌شده این تبدیل را انجام میدهد و افزودن منطق موازی می‌تواند اختلاف تازه بسازد.
از میزبان بخواهید توضیح دهد اتصال بازدیدکننده در کدام نقطه رمزگشایی میشود و برنامه از چه راه معتبری طرح اصلی را می‌فهمد. اگر پاسخ فقط نام یک گزینه در پنل است، هنوز رابطهٔ آن با مبدا روشن نشده است. تغییر حالت ارتباط لبه و مبدا باید با پشتیبانی معتبر TLS در مبدا و سیاست همان زیرساخت هماهنگ باشد. پایین‌آوردن امنیت اتصال برای ناپدیدکردن پیام مرورگر، معیار تعمیر این مسئله نیست.
هدر فورواردشده فقط با مرز اعتماد معتبر است
هدر مربوط به طرح اتصال می‌تواند به برنامه کمک کند، اما فقط وقتی از پراکسی مورد اعتماد برسد و مسیر جعل آن بسته باشد. اگر کاربر اینترنتی بتواند همان هدر را مستقیم به مبدا بفرستد و برنامه بی‌قید آن را بپذیرد، تشخیص امنیت به ورودی نامطمئن وابسته میشود. به همین دلیل این مقاله کد عمومی برای پذیرش هر مقدار هدر ارائه نمیکند. ابتدا باید معماری و مسئول کنترل مرز مشخص باشد.
مرجع تابع is_ssl در وردپرس نحوهٔ تشخیص اتصال امن در برنامه و ملاحظات پراکسی را نشان میدهد. در استقرار واقعی، مسئول فنی باید تعیین کند هدر ورودی بیرونی حذف یا بازنویسی میشود، مبدا از کجا قابل دسترسی است و چند واسطه در مسیر قرار دارند. وجود نام هدر به‌تنهایی شاهد صحت آن نیست. همچنین مقدار چندبخشی ناشی از چند واسطه را نباید با یک شرط ساده و بدون قرارداد روشن تفسیر کرد.
پس از اصلاح، یک درخواست از مسیر مجاز عمومی و بررسی کنترل‌شدهٔ مسیر مبدا باید نشان دهد برنامه برداشت سازگاری دارد. دسترسی مستقیم به مبدا را برای آزمایش همگانی باز نکنید؛ بررسی آن با مسئول زیرساخت انجام میشود. گزارش نتیجه باید بگوید کدام لایه مقدار را معتبر کرده است. عبارت مبهم «هدر HTTPS اضافه شد» برای نگهداری آینده کافی نیست و ممکن است در تغییر CDN بعدی دوباره مشکل ایجاد کند.
Apache؛ قواعد پراکنده و ترتیب اجرای آنها
در Apache، انتقال ممکن است در تنظیمات میزبان مجازی، فایل پوشه یا قواعدی که پنل میزبانی می‌سازد قرار داشته باشد. دیدن یک فایل خالی به معنای نبود انتقال در سرور نیست. از مسئول میزبان بخواهید منابع مؤثر بر همان دامنه را بررسی کند. اگر چند مدیر از ابزارهای مختلف استفاده کرده‌اند، دو قانون ظاهراً منطقی می‌توانند مقصدهای مخالف داشته باشند؛ برای مثال یکی دامنه را بدون www و دیگری با آن تثبیت کند.
مستند رسمی mod_alias ابزارهای انتقال نشانی در Apache را شرح میدهد. در کار تشخیصی، لازم است معلوم شود قانون از چه سازوکاری آمده و در چه زمینه‌ای اجرا میشود. افزودن یک قانون دیگر در انتهای فایل الزاماً قانون قبلی را خنثی نمیکند. همچنین حذف یک بلوک بزرگ به امید حذف حلقه ممکن است انتقال‌های معتبر قدیمی یا رفتارهای دیگر سایت را از بین ببرد.
نسخهٔ قبل را نگه دارید، قانون متضاد را مشخص کنید و در محیط آزمایشی فقط همان بخش را تغییر دهید. اگر تغییر از پنل تولید میشود، ویرایش دستی خروجی ممکن است با ذخیرهٔ بعدی پنل بازنویسی شود؛ منبع تنظیم را اصلاح کنید. صحت پیکربندی و روش اعمال آن مسئولیت مدیر سرور است. برای سایت فعال، بازخوانی کنترل‌شده و امکان برگشت باید پیش از اعمال معلوم باشد، نه پس از مشاهدهٔ خرابی تازه.
nginx؛ تمایز انتقال بیرونی و مسیریابی داخلی
در nginx، همهٔ بازنویسی‌ها انتقال مرورگر نیستند. بعضی تغییرها در داخل پردازش درخواست رخ می‌دهند و بعضی با پاسخ انتقال، نشانی تازه‌ای به مرورگر می‌دهند. زنجیره‌ای که در ابزار شبکه می‌بینید مربوط به پاسخ‌های بیرونی است؛ نتیجهٔ یک حلقهٔ داخلی ممکن است رفتار متفاوتی داشته باشد. پیش از دستکاری، از مدیر بخواهید مشخص کند کدام دستور واقعاً Location تولید میکند و کدام فقط مسیر داخلی را انتخاب میکند.
مرجع رسمی ماژول rewrite در nginx تفاوت سازوکارهای بازنویسی و return را توضیح میدهد. برای تشخیص این خطا، بلوک فعال دامنه و قواعد پاسخ بیرونی مهم‌اند. کپی یک دستور از نمونهٔ اینترنتی بدون بررسی نام میزبان، اتصال پشت پراکسی و مسیر نصب ممکن است حلقه را از یک جفت نشانی به جفت دیگری منتقل کند. پیکربندی درست باید با معماری همین سایت سازگار باشد.
اگر nginx جلوی Apache یا برنامه قرار دارد، مقصدی که مبدا می‌فرستد نیز باید بررسی شود. مستند رسمی ماژول proxy در nginx رفتارهای مرتبط با هدرهای پراکسی و بازنویسی مقصد پاسخ را شرح میدهد. اینجا باید روشن شود مقصد نامناسب در مبدا ساخته شده یا در واسطه تغییر کرده است. اصلاح در محل اشتباه شاید یک صفحه را باز کند اما نشانی فایل‌ها و مسیرهای دیگر را ناسازگار باقی بگذارد.
CDN و کش پاسخ‌های انتقال
شبکهٔ توزیع محتوا می‌تواند هم تولیدکنندهٔ انتقال باشد و هم پاسخ انتقال مبدا را نگه دارد. این دو نقش را از هم جدا کنید. اگر قانون لبه کاربر را به مقصدی می‌برد، تغییر افزونهٔ وردپرس ممکن است اصلاً دیده نشود. اگر لبه فقط پاسخ قدیمی را نمایش میدهد، قانون مبدا شاید اصلاح شده باشد اما مشاهدهٔ عمومی هنوز قدیمی بماند. برای تصمیم، زمان پاسخ و شواهد کش را با مسئول همان سرویس مقایسه کنید.
از پاککردن بی‌هدف همهٔ کش‌ها شروع نکنید. ابتدا مسیر و نسخهٔ دامنهٔ درگیر را مشخص کنید و پاکسازی مرتبط را انجام دهید. در سایت پرترافیک، پاکسازی فراگیر می‌تواند فشار تازه‌ای به مبدا وارد کند. اگر ارائه‌دهنده راه مشاهدهٔ امن و مجاز پاسخ مبدا دارد، با همکاری او مقایسه کنید؛ تغییر DNS عمومی یا بازکردن مستقیم مبدا برای تمام کاربران، آزمون کوچک و بدون پیامد نیست.
پس از اصلاح، فقط یک مرورگر را نبینید. نسخهٔ دامنهٔ قدیمی، لینک ورودی رایج و یک مسیر داخلی را آزمایش کنید. ممکن است کش برای هرکدام کلید جداگانه داشته باشد. اگر یک منطقه هنوز خراب است، زمان و مسیر دقیق را گزارش کنید و از ساختن قوانین جبرانی برای هر مشاهدهٔ پراکنده بپرهیزید. هدف، رسیدن به یک قرارداد سازگار در لایه‌ها است، نه انباشتن استثناهایی که بعدها خودشان حلقه بسازند.
کوکی و دادهٔ محلی؛ آزمون محدود با تفسیر درست
پنجرهٔ خصوصی کمک میکند وابستگی به وضعیت محلی را بسنجید. اگر آنجا سالم است، دادهٔ ذخیره‌شدهٔ مرورگر، کوکی دامنه یا انتقال قدیمی می‌تواند در اختلاف نقش داشته باشد. با این حال پنجرهٔ خصوصی ممکن است افزونه‌های مرورگر یا شرایط دیگری را هم تغییر دهد؛ پس نتیجهٔ آن یک سرنخ است. قبل از پاککردن داده، زنجیرهٔ خراب را ثبت کنید تا شواهد از بین نرود.
در صورت نیاز فقط دادهٔ همان سایت را پاک کنید و به کاربر اطلاع دهید ممکن است از حساب خارج شود یا سبد محلی تغییر کند. پاککردن همهٔ مرورگر برای تشخیص یک سایت ضرورتی ندارد. پس از پاکسازی، همان نشانی شروع را تکرار کنید. اگر مشکل برمی‌گردد، علت تولید وضعیت ناسازگار هنوز باقی است و توصیهٔ همیشگی به پاککردن کوکی راه‌حل مدیریتی مناسبی محسوب نمی‌شود.
تغییر نسخهٔ دامنه می‌تواند دامنهٔ اثر کوکی را هم مهم کند، به‌ویژه در حساب کاربری و فروشگاه. این موضوع را با حلقهٔ عمومی HTTP مخلوط نکنید. اگر مهمان و صفحههای عمومی سالم‌اند و فقط حساب خراب است، مسیر اختصاصی نشست را دنبال کنید. برای حلقهٔ عمومی، موفقیت یک مرورگر پاک کافی نیست؛ باید زنجیرهٔ بدون کوکی نیز به مقصد نهایی درست برسد و کاربران قدیمی راه بازیابی روشن داشته باشند.
افزونه‌های تغییر مسیر، زبان و اجبار اتصال امن
فهرست ابزارهایی را که ممکن است نشانی را تغییر دهند تهیه کنید: مدیریت ریدایرکت، زبان، عضویت، اجبار HTTPS و افزونه‌های مرتبط با مهاجرت. وجود چند ابزار الزاماً خطا نیست، اما مسئولیت مشترک بدون قرارداد می‌تواند تعارض ایجاد کند. برای هر انتقال مشاهده‌شده، دنبال قاعده‌ای با همان مبدأ و مقصد بگردید. نام افزونه را از روی حدس انتخاب نکنید و همهٔ افزونه‌ها را در سایت زنده هم‌زمان خاموش نکنید.
در محیط آزمایشی، فقط قابلیت مشخص یا قانون مظنون را موقتاً تغییر دهید و نتیجهٔ زنجیره را مقایسه کنید. اگر حلقه رفع شد، هنوز باید قانون جایگزین درست را بسازید؛ خاموش‌ماندن یک قابلیت ضروری پایان کار نیست. برای افزونهٔ زبان، مسیر پیش‌فرض و زبان دوم را جدا ببینید. هدایت خودکار براساس زبان مرورگر ممکن است با قانون ثابت حذف پیشوند تداخل داشته باشد و فقط برای بخشی از کاربران ظاهر شود.
قواعد امنیتی را با قواعد نشانی یکی ندانید. میتوان قانون انتقال اشتباه را اصلاح کرد بدون آنکه حفاظت عمومی سایت کنار گذاشته شود. اگر ابزار اجازهٔ تفکیک نمی‌دهد، تغییر زنده را متوقف کنید و راه آزمایش محدود را با مسئول فنی انتخاب کنید. برای مرور مرزهای دسترسی و تنظیمات مرتبط، چک‌لیست امنیت سایت مسیر مکمل است؛ هدف این بررسی حفظ امنیت همراه با اصلاح مسیریابی است.
اسلش، پارامتر و مسیرهای وابسته به زبان
حلقه همیشه میان HTTP و HTTPS نیست. یک قانون ممکن است اسلش پایانی را اضافه کند و قانون دیگری آن را حذف کند. همین تعارض می‌تواند میان مسیر دارای پیشوند زبان و مسیر بدون آن رخ دهد. اگر فقط یک خانوادهٔ صفحه خراب است، چند نمونه از همان خانواده انتخاب کنید و نشانی تولیدشدهٔ داخل سایت را با مقصد قواعد مقایسه کنید. تفاوت مسیر را دقیق بنویسید؛ عبارت «هر دو یک صفحه‌اند» برای تشخیص کافی نیست.
پارامترهای رهگیری نیز ممکن است وارد تعارض شوند. یک ابزار پارامتر را اضافه میکند و ابزار دیگر برای پاکسازی آن انتقال میدهد، سپس شرط اول دوباره فعال میشود. آزمایش را از نشانی پایه شروع کنید و هر بار فقط یک پارامتر عمومی و غیرحساس اضافه کنید. اگر حلقه فقط با ترکیب خاصی رخ میدهد، همان ترکیب حداقلی را ثبت کنید. حذف سراسری پارامترها ممکن است فیلتر، جست‌وجو یا رفتار فروشگاه را خراب کند.
قانون نهایی باید استثناهای عملیاتی را بشناسد. مسیر برگشت پرداخت، صفحهٔ حساب و رابط داده را مانند یک مقالهٔ عمومی فرض نکنید. پیش از تعمیم یک قانون به تمام مسیرها، اثر آن بر این بخش‌ها را در محیط مجاز بسنجید. اگر فقط نسخهٔ زبان دوم مشکل دارد، قواعد دامنهٔ اصلی را دستکاری نکنید مگر آنکه زنجیره ارتباط مستقیم را نشان دهد. محدودکردن دامنهٔ تغییر، فهم نتیجه را ساده‌تر میکند.
سناریوی فرضی اول؛ HTTPS در لبه و تشخیص اشتباه مبدا
سایتی فرضی را تصور کنید که پس از فعالسازی CDN، تمام صفحههای عمومی در حلقه افتاده‌اند. این روایت گزارش آزمایش واقعی نیست. فرضیهٔ اول کوکی خراب، فرضیهٔ دوم انتقال متضاد دامنه و فرضیهٔ سوم تشخیص نادرست اتصال امن در مبدا است. مسئول سایت خانه و یک مقاله را در پنجرهٔ خصوصی امتحان میکند و همان مشکل را می‌بیند؛ بنابراین مشکل صرفاً وابسته به نشست قدیمی نیست، هرچند کش همچنان باید بررسی شود.
زنجیره نشان میدهد نشانی HTTPS بارها به همان مقصد امن هدایت میشود. این مشاهده به‌تنهایی علت را ثابت نمیکند، اما با بررسی میزبان روشن میشود TLS در لبه پایان می‌یابد و برنامه برداشت درستی از اتصال اصلی ندارد. مسئول زیرساخت ابتدا مرز اعتماد را بررسی میکند: چه کسی هدر را می‌سازد و آیا درخواست مستقیم اینترنت می‌تواند آن را جعل کند؟ سپس همان سازوکار معتبر اطلاعرسانی به برنامه را اصلاح میکند، نه اینکه وردپرس را برای همیشه روی HTTP نگه دارد.
معیار نتیجه، رسیدن درخواست عمومی به محتوای درست و حذف انتقال تکراری است. خانه و مقاله، نسخهٔ قدیمی HTTP و یک مسیر فروشگاهِ مجاز جدا آزمایش می‌شوند. اگر فقط یک صفحه باز شود ولی نسخهٔ دیگر دامنه هنوز بچرخد، تعمیر کامل نیست. اگر تشخیص امنیت از هدر نامطمئن پذیرفته شود، نتیجه از نظر معماری قابل قبول نیست. در صورت شکست، تغییر اخیر برمی‌گردد و شواهد مسیر لبه تا مبدا برای بررسی دقیق‌تر حفظ میشود.
سناریوی فرضی دوم؛ تعارض دامنه پس از مهاجرت
در مثال آموزشی دیگری، سایتی بعد از مهاجرت بیشتر اوقات از خانه باز میشود اما لینک‌های قدیمی کاربران خطای انتقال می‌دهند. سه فرضیه وجود دارد: کش مرورگر، قانون قدیمی در افزونه و قانون ناسازگار در پنل سرور. مسئول محتوا لینک دقیق قدیمی را می‌گیرد و مشاهده میکند نسخهٔ بدون www به نسخهٔ دارای www می‌رود و سپس برمی‌گردد. این شکل زنجیره مسئله را به قرارداد دامنه محدود میکند و بررسی پیوند یکتای نوشته را در اولویت دوم می‌گذارد.
در فرض این داستان، پنل میزبان نسخهٔ دارای www را مرجع می‌داند، اما ابزار مهاجرت در برنامه قانون معکوس باقی گذاشته است. تیم ابتدا تصمیم فعلی دامنه را با مالک سایت تأیید میکند و گواهی و لینک‌های تولیدشده را می‌بیند. سپس در محیط آزمایشی فقط قانون قدیمی ناسازگار را اصلاح میکند. اگر حلقه بدون آن قانون ادامه یابد، فرضیه رد شده و باید لایهٔ دیگر بررسی شود؛ نتیجهٔ مطلوب را نباید صرفاً به دلیل پیدا شدن یک قانون مشکوک اعلام کرد.
پس از اصلاح، هر چهار ترکیب عمومی دامنه و اتصال باید به مقصد تعریف‌شده برسند و یک مقالهٔ داخلی محتوای خودش را نشان دهد. مقصد نباید بی‌دلیل خانه باشد و پارامترهای مجاز لازم نباید گم شوند. کش مرتبط پاک میشود و لینک داخلی قدیمی نیز اصلاح می‌گردد. معیار پایان، سازگاری واقعی زنجیره است؛ کم‌شدن شکایت‌ها یا بازشدن یک مرورگر، به‌تنهایی اثبات رفع تعارض همهٔ ورودی‌ها نیست.
موبایل و ووکامرس؛ بررسی فراتر از خانه
کاربر موبایل ممکن است از لینک داخل شبکهٔ اجتماعی وارد شود، در حالی که آزمایش مدیر از بوکمارک مستقیم خانه انجام میشود. برای مقایسه، همان نشانی آغاز و نسخهٔ دامنه را استفاده کنید. مرورگر درون‌برنامه‌ای ممکن است دادهٔ محلی متفاوتی داشته باشد؛ اختلاف را با کد سند و زنجیره بسنجید، نه فقط با ظاهر صفحه. اگر لینک کوتاه‌شده یک سرویس بیرونی در حلقه است، مسئول آن مسیر را از وردپرس جدا کنید.
در ووکامرس، تغییر دامنه یا اتصال می‌تواند به نشست سبد و مسیر بازگشت پرداخت مربوط شود. پیش از تغییر زنده، مسئول سفارشها باید از عملیات آگاه باشد و راه پیگیری تراکنش‌های باز مشخص شود. روی سفارش واقعی برای آزمون رفت‌وبرگشت کلیک تکراری نکنید. از روش آزمایشی مجاز و محیط جدا از پرداخت واقعی استفاده کنید و نشانی‌های دارای شناسهٔ حساس را در گزارش عمومی نیاورید.
پس از تعمیر، محصول، سبد، تسویه و بازگشت مجاز را با نقش‌های لازم بررسی کنید. دریافت پاسخ موفق از محصول، سلامت جریان پرداخت را ثابت نمیکند. اگر تغییر به نشست کاربران قدیمی اثر گذاشته، راهنمای محدود بازیابی دادهٔ همان سایت را آماده کنید. بازگرداندن پایگاه داده برای اصلاح یک قانون انتقال، ممکن است دادهٔ سفارشهای تازه را حذف کند؛ نسخهٔ بازگشت باید تا حد ممکن همان تنظیم تغییرکرده باشد.
پیامد HTTP، canonical و دیده‌شدن در جست‌وجو
حلقه اجازه نمی‌دهد درخواست به محتوای نهایی برسد؛ بنابراین افزودن canonical به صفحه‌ای که قابل دریافت نیست مشکل مسیر را حل نمیکند. ابتدا انتقال‌ها را به مقصد درست و قابل دسترس برسانید، سپس canonical، نقشهٔ سایت و لینک‌های داخلی را با همان قرارداد هماهنگ کنید. اگر صفحهٔ داخلی بعد از اصلاح به خانه هدایت میشود، صرف پایان‌یافتن حلقه کافی نیست؛ مقصد باید با نیاز کاربر و محتوای قبلی سازگار باشد.
راهنمای رسمی گوگل دربارهٔ ریدایرکت‌ها انتقال دائمی و موقت را از نظر کاربرد توضیح میدهد. نوع پاسخ باید با قصد واقعی جابه‌جایی سازگار باشد و نمی‌توان از انتخاب یک کد، وعدهٔ رتبه یا زمان بازیابی نتیجه گرفت. در دورهٔ بررسی، تغییرهای آزمایشی را بی‌دلیل به قوانین دائمی تبدیل نکنید؛ انتقال ذخیره‌شده در واسطه یا مرورگر می‌تواند ارزیابی اصلاح بعدی را پیچیده کند.
پس از تثبیت، لینک‌های داخلی را مستقیم به نسخهٔ نهایی ببرید و نشانی‌های نامعتبر را از نقشهٔ سایت کنار بگذارید. خروجی تولیدکنندهٔ canonical را بررسی کنید تا دامنهٔ قدیمی باقی نمانده باشد. اگر بررسی فنی و محتوایی گسترده‌تر لازم است، سئوی سایت باید از شواهد واقعی پاسخ‌ها و هدف صفحات شروع شود. گزارش ابزار جست‌وجو برای پیگیری مفید است، اما جای مشاهدهٔ زنجیرهٔ زنده و اصلاح منبع قانون را نمی‌گیرد.
آزمون پذیرش، بازگشت و ارجاع مسئولانه
پذیرش را با ورودیهای متفاوت انجام دهید: خانهٔ مرجع، یک مقاله، نسخهٔ قدیمی دامنه، HTTP و HTTPS و مسیرهای حساس توافق‌شده. برای هر ورودی، مقصد نهایی و محتوای درست را ثبت کنید. لازم نیست تمام مسیرها صفر انتقال داشته باشند؛ انتقال نسخهٔ قدیمی به نسخهٔ مرجع می‌تواند هدفمند باشد. آنچه مردود است بازگشت به گام قبلی، مقصد نامرتبط یا زنجیره‌ای است که به قانون‌های متضاد وابسته می‌ماند.
در صورت ایجاد خرابی تازه، همان تنظیم اخیر را به نسخهٔ ثبت‌شده برگردانید و پاسخ تازه بگیرید. اگر اثر تغییر در کش باقی مانده، پاکسازی هدفمند را با مسئول لایه انجام دهید. برگشت را با مشاهدهٔ نتیجه تأیید کنید، نه فقط با دیدن مقدار قدیمی در پنل. اگر دسترسی به لایهٔ مؤثر ندارید، از افزودن قوانین جبرانی در لایهٔ دیگر خودداری کنید؛ این کار مسئولیت مقصد را مبهم‌تر میکند.
بستهٔ ارجاع شامل نشانی عمومی شروع، زنجیرهٔ پاک‌سازی‌شده، زمان، حالت مرورگر، آخرین تغییر و فهرست لایه‌های شناخته‌شده باشد. سؤال مشخص بپرسید: این پاسخ انتقال در کدام لایه تولید میشود و چرا مقصدش با قرارداد دامنه مخالف است؟ اگر پایان TLS معلوم نیست، همین نادانسته را صریح ثبت کنید. تحویل خوب باید معیار پایان داشته باشد تا مسئول بعدی نیز بداند چه رفتاری باید اثبات شود.
ثبت وضعیت پایدار پس از رفع حلقه
برای تحویل، فقط تصویر صفحهٔ بازشده را نگه ندارید. نشانی آغاز، مقصد نهایی و تعداد گام‌های مشاهده‌شده را همراه با حالت کاربر ثبت کنید. این سابقه در تغییر بعدی نشان میدهد آیا رفتار تازه واقعاً متفاوت شده است یا فقط روش آزمایش فرق کرده است. اگر قانون موقت برای دورهٔ مهاجرت باقی می‌ماند، مسئول بازبینی و شرط حذف آن را مشخص کنید تا به بخشی فراموش‌شده از پیکربندی تبدیل نشود.
به تیم محتوا نیز نسخهٔ درست دامنه را اعلام کنید تا لینک‌های تازه دوباره از ورودی قدیمی ساخته نشوند. اگر سامانهٔ ارسال خبرنامه یا ابزار انتشار خودکار نشانی را تولید میکند، خروجی آن را هم ببینید. ممکن است وردپرس سالم باشد اما یک ابزار جانبی همچنان مقصد ناسازگار بسازد. اصلاح این منبع با افزودن قانون انتقال تازه تفاوت دارد؛ تولید لینک درست، وابستگی بعدی را کاهش میدهد و تشخیص خطای آینده را روشن‌تر میکند.
پیشگیری با یک مالک روشن برای هر قانون
برای اجبار HTTPS و نسخهٔ دامنه، مسئول اصلی و محل پیکربندی را مستند کنید. وجود یک قرارداد روشن به این معنا نیست که هیچ لایهٔ دیگری اطلاعات مربوط را نمی‌داند؛ یعنی قواعد نباید مقصدهای متضاد تولید کنند. هنگام افزودن CDN، مهاجرت میزبان یا نصب افزونهٔ زبان، این قرارداد را دوباره بررسی کنید. تنظیمات قدیمی نباید فقط چون فعلاً مزاحم نیستند بدون مالک در سامانه بمانند.
پس از هر تغییر زیرساخت، چند ورودی ثابت را به فهرست تحویل اضافه کنید و زنجیرهٔ قبل و بعد را نگه دارید. یک صفحهٔ عمومی، نسخهٔ دیگر دامنه و مسیر مهم فروشگاه معمولاً سرنخ‌های متفاوتی می‌دهند. اگر ابزار پایش دارید، پایان موفق درخواست و مقصد مورد انتظار را بررسی کنید؛ مشاهدهٔ پاسخ اولیهٔ انتقال به‌تنهایی سلامت صفحه را ثابت نمیکند. همچنین مسیرهای خصوصی را بدون مجوز در ابزار بیرونی پایش قرار ندهید.
وقتی حلقه برطرف شد، قوانین موقت و استثناهای آزمایشی را مرور کنید و فقط موارد لازم را با دلیل نگه دارید. برای هر قانون توضیح کوتاهی دربارهٔ هدف و دامنهٔ اثر بنویسید. این مستندسازی از اصلاح دوبارهٔ همان نشانه در مهاجرت بعدی جلوگیری میکند. تمرکز نگهداری باید بر سازگاری مسیر درخواست و امکان بازگشت باشد، نه تعداد ابزارهایی که هرکدام جداگانه گزینهٔ «اصلاح ریدایرکت» ارائه می‌کنند.