הגדרת פרוקסי ללקוח ASP.NET Core SignalR לפני ההפעלה

הגדירו לקוח ASP.NET Core SignalR דרך HttpConnectionOptions כדי שהמשא ומתן והתעבורה שנבחרה יעברו במסלול המיועד.

לפני הפעלת לקוח ASP.NET Core SignalR, הגדירו את אפשרויות החיבור שלו:

var connection = new HubConnectionBuilder()
    .WithUrl("https://events.example/hub", options =>
    {
        options.Proxy = new WebProxy("http://proxy.example:8080");
    })
    .Build();

קטע זה משתמש בלקוח SignalR המודרני וב-System.Net. נהלו connection לאורך מחזור החיים האסינכרוני של היישום; השאירו את כתובת ה-hub כיעד. לבדיקת hub ציבורי מותרת ללא פרטי פרוקסי מוגדרים, רשימת פרוקסי ה-HTTP מספקת מתווכי HTTP מועמדים.

הגדרת התעבורההיכן הפרוקסי חל
התנהגות חיבור ברירת מחדלHttpConnectionOptions.Proxy בוחר את המתווך; תעבורת ה-WebSocket המוגדרת כברירת מחדל ב-.NET 8 מקצה אותו גם ל-ClientWebSocketOptions
HttpMessageHandlerFactoryמתאים אישית את טיפול ה-HTTP, לא חיבורי WebSocket
יצרן WebSocketFactoryשהוזן מחזיק בהתנהגות היצירה שלו וחייב להחיל את המסלול הנדרש

משא ומתן מוצלח אינו מוכיח שמנהרת ה-WebSocket המאוחרת התקבלה. אם WebSocketFactory מותאם משתמש ב-.NET ClientWebSocket, הגדירו את הפרוקסי של אותו socket לפני החיבור. קראו אבחון תעבורה עבור השלב האחרון שהושלם ובחנו גם כל תעבורת גיבוי מכוונת.

דוגמאות ASP.NET SignalR ישנות יותר שמגדירות Connection.Proxy שייכות לדור אחר. עם HubConnectionBuilder, השאירו את הפרוקסי עם שאר WithUrl אפשרויות התעבורה במקום להגדיר בקשת HTTP לא קשורה.

מאמרים קשורים