سلامت پروکسی: کدام وب‌سایت و کدام عملیات را آزمایش کردید؟
هنگام نگهداری یک استخر پروکسی قابل استفادهٔ مجدد، دسترس‌پذیری عمومی پروکسی را از شکست‌های مخصوص مقصد جدا کنید.
پروکسی صفحهٔ بررسی IP شما را می‌آورد اما در API موردنیاز برنامهٔ شما شکست می‌خورد. نامیدن آن «سالم» یا «مرده» سرنوشت‌سازترین واقعیت را از دست می‌دهد: دو درخواست متفاوت بودند.
با یک سابقهٔ سراسری انتقال برای نقطهٔ پایانی شروع کنید. آیا می‌توانید به شنوندهٔ آن برسید و مذاکرهٔ لازم پروکسی را کامل کنید؟ مشاهدات مخصوص مقصد را کنار آن سابقه نگه دارید، نه اینکه آن را بازنویسی کنید.
| مشاهده | دامنهٔ بررسی |
|---|---|
| شنوندهٔ پروکسی اتصال‌ها را رد می‌کند | نقطهٔ پایانی و مسیر رسیدن به آن |
| پروکسی یک درگاه مقصد را رد می‌کند | عملیات مجاز برای آن مقصد |
| یک وب‌سایت خطای حساب برمی‌گرداند | برنامهٔ مقصد و اعتبارنامه‌ها |
| پاسخ‌های بزرگ متوقف می‌شوند، کوچک‌ها تمام می‌شوند | بار کاری انتقال و سیاست مهلت |
یک پاسخ HTTP می‌تواند ثابت کند که مسیر درخواست چیزی برگردانده، درحالی‌که هنوز برای برنامه بی‌فایده است. موفقیت انتقال، وضعیت HTTP و محتوای مورد انتظار را به‌عنوان نتایج جداگانه نگه دارید.
اگر یک مقصد مکرراً شکست می‌خورد، آن جفت نقطهٔ پایانی و مقصد را متوقف یا بررسی کنید. غیرفعال کردن پروکسی برای هر کار نامرتبط ممکن است ظرفیت مفیدی را هدر دهد. در مقابل، شکست اتصال سراسری نباید پشت سابقهٔ جداگانهٔ یک وب‌سایت پنهان بماند.
یک کلید سلامت عملی می‌تواند شناسهٔ پروکسی، سرویس مقصد و نوع عملیات را دربر بگیرد. از استفاده از کل URL حاوی اعتبارنامه یا هر مسیر منحصربه‌فرد منبع به‌عنوان کلیدی که پیوسته رشد می‌کند بپرهیزید. فقط جایی گروه‌بندی کنید که گروه‌بندی پیش‌بینی معناداری دربارهٔ درخواست بعدی می‌دهد.
هدف شواهد مسیریابی بهتر است، نه مجموعهٔ بزرگ‌تری از نشان‌های سبز. نتیجهٔ سلامت باید بگوید چه چیزی آزمایش شد، چه وقت، و واقعاً چه چیزی را ثابت کرد.