چرا خطای پروکسی SockJS ممکن است فقط پس از بازگشت به مسیر جایگزین ظاهر شود
مسیر WebSocket و مسیر جایگزین XHR ممکن است از کلاینت‌های HTTP متفاوت استفاده کنند. پیش از تغییر تنظیمات پروکسی، انتقال ناموفق را شناسایی کنید.
وقتی WebSocket در یک شبکه کار می‌کند ولی SockJS در شبکه دیگر شکست می‌خورد، ممکن است شبکه دوم مسیر جایگزین XHR را فعال کرده باشد. این می‌تواند پیاده‌سازی HTTP را که درخواست‌ها را انجام می‌دهد تغییر دهد — و در نتیجه پیکربندی پروکسی مورد استفاده را نیز.
نخستین URL ناموفق و انتقال انتخاب‌شده برای آن را پیدا کنید. SockJS ممکن است پیش از انتخاب انتقال، یک درخواست اطلاعاتی HTTP ارسال کند؛ دست‌دادن WebSocket و درخواست‌های نظرسنجی بعدی عملیات‌های جداگانه‌ای هستند. پیکربندی دست‌دادنِ کارآمد مسیر استفاده‌شده برای هر یک از آن‌ها را اثبات نمی‌کند.
در کلاینت Java اسپرینگ، RestTemplateXhrTransport یک RestTemplate پیکربندی‌شده را می‌پذیرد. کارخانه درخواست و کلاینت HTTP زیربنایی آن، مسیر پروکسی و احراز هویت پشتیبانی‌شده توسط مسیر جایگزین را فراهم می‌کنند. برای Spring 6 با HttpClient 5، کارخانه درخواست واقعی همان RestTemplate را پیکربندی کنید. اگر آن پیاده‌سازی از اجزای Apache HTTP استفاده می‌کند، نسل آن باید با یکپارچه‌سازی هم‌خوان باشد.
کلاینت WebSocket تنظیمات اتصال مستند خودش را دارد. ویژگی‌های پروکسی JVM فقط زمانی بر یک مسیر اثر می‌گذارند که کلاینت مشخص آن آن‌ها را بخواند. محیط‌های کارآمد و ناموفق را بر اساس انتقال، پیاده‌سازی کلاینت، پروکسی انتخاب‌شده و نخستین خطا مقایسه کنید. اگر تنها XHR شکست می‌خورد، به جای تغییر مکرر تنظیمات کلاینت WebSocketِ کارآمد، مسیر، احراز هویت و پاسخ‌های طولانی‌مدت آن را دنبال کنید.