در مورد تاریخی پروکسی HTTP سیستمی، OkHttp رفتار خود را در نسخهٔ 3.5.0 تغییر داد: پس از شکست آن پروکسی، دیگر اتصال مستقیم را امتحان نکرد. گزارشی قدیمی‌تر دربارهٔ بازگشت بی‌صدا ممکن است رفتار پیش از این تغییر را توصیف کند.

آن تاریخچه سیاست مسیریابی هر برنامه‌ای را روشن نمی‌کند. برای تفسیر گزارشی از برنامهٔ خودتان، این سه بررسی را دنبال کنید:

  1. نسخهٔ حل‌شدهٔ OkHttp را پیدا کنید. از اطلاعات وابستگی‌های برنامه استفاده کنید، از جمله نسخه‌ای که یک چارچوب واقعاً بسته‌بندی کرده است، نه سن نمونه‌ای که کپی می‌شود.
  2. پیدا کنید این کلاینت چگونه مسیر را انتخاب می‌کند. پروکسی صریح و ProxySelector سفارشی پیکربندی‌های متفاوتی هستند. اگر انتخاب‌گر پس از یک پروکسی نامزد مستقیم ارائه دهد، در حال پیشنهاد یک جایگزین مستقیم است.
  3. کنترل‌کنندهٔ شکست را دنبال کنید. کد برنامه‌ای را جستجو کنید که با کلاینت دیگری تلاش مجدد می‌کند. درخواست مستقیمی که آن جانشین انجام می‌دهد خارج از تصمیم کلاینت اول است.

برای الزام پروکسی اجباری، سیاست مربوط به کلاینت باید متوقف شود نه اینکه جایگزین مستقیم پیشنهاد دهد. کلاینت واقعی و مسیر تلاش مجدد را در برابر آن الزام بررسی کنید؛ تغییر 3.5.0 به‌تنهایی قاعدهٔ ترافیک در سطح کل ماشین نیست.

مقالات مرتبط