Scrapy می‌تواند تغییرمسیر را پیش از دنبال‌کردن نشان دهد
وضعیت اولیهٔ تغییرمسیر و هدر Location یک درخواست GET از طریق پراکسی را به‌طور موقت با فراداده‌های درخواست آشکار کنید و مدیریت تغییرمسیر را از فیلتر خطاهای HTTP جدا نگه دارید.
یک GET از طریق پراکسی می‌تواند به سروری برسد و سپس تغییرمسیرها را دنبال کند تا شکست نهایی پاسخ نخست را پنهان کند. آن پاسخ اولیه را برای عیب‌یابی آشکار کنید:
request = scrapy.Request(
'https://service.example/page',
callback=inspect_redirect,
meta={
'proxy': 'http://proxy.example:8080',
'dont_redirect': True,
'handle_httpstatus_list': [301, 302, 303, 307, 308],
},
)این درخواست را از طریق جریان شروع یا callback موجود عنکبوت زمان‌بندی کنید. برای یک بررسی مجاز روی صفحهٔ عمومی، فهرست پراکسی HTTP نامزدهایی برای URL پراکسی درخواست فراهم می‌کند. inspect_redirect باید وضعیت پاسخ و هدر Location را ثبت کند، نه اینکه دوباره کورکورانه آن را دنبال کند.
dont_redirect تغییرمسیر خودکار را برای این درخواست متوقف می‌کند. handle_httpstatus_list اجازه می‌دهد وضعیت‌های نام‌برده به callback برسند، به‌جای اینکه با فیلتر خطاهای HTTP رد شوند. این تنظیمات به مسئولیت‌های متفاوت middleware مربوط‌اند.
بررسی کنید تغییرمسیر چه چیزی را انتخاب می‌کند: یک URL متعارف موردنظر، طرح یا نام میزبان متفاوت، صفحهٔ ورود یا چرخه‌ای تکرارشونده. دریافت 302 پس از انتقال موفق، مشاهده‌ای متفاوت از ناتوانی در بازکردن اتصال پراکسی است.
وقتی مدیریت عادی تغییرمسیر بازگردانده شود، Scrapy دو فیلد redirect_urls و redirect_reasons را در فراداده‌های درخواست پاسخ آشکار می‌کند. این‌ها می‌توانند مسیر منتهی به نتیجهٔ نهایی را حفظ کنند بدون آنکه تغییرمسیرها برای کل خزش غیرفعال بمانند.
پاسخ پایانی به‌طور خودکار همان صفحه‌ای نیست که برنامه قصد داشت. مقصد و محتوای پاسخ را همراه با عیب‌یابی مسیریابی نگه دارید.