Problembehandlungsleitfaden für häufig bei Azure SignalR Service auftretende Probleme

  • Artikel

In diesem Artikel finden Sie einen Leitfaden zur Problembehandlung für einige häufig auftretende Probleme.

Zugriffstoken zu lang

Mögliche Fehler:

  • ERR_CONNECTION_ auf Clientseite
  • 414 – URI zu lang
  • 413 Nutzlast zu groß
  • Das Zugriffstoken darf nicht länger als 4 K sein. 413 – Anforderungsentität zu groß

Tiefere Ursache

Bei HTTP/2 beträgt die Höchstlänge für einen einzelnen Header 4 K, wenn Sie daher mit einem Browser auf den Azure-Dienst zugreifen, tritt aufgrund dieser Begrenzung ein ERR_CONNECTION_-Fehler auf.

Bei HTTP/1.1 und C#-Clients beträgt die Höchstlänge von URIs 12 K, und die Höchstlänge für Header ist 16 K.

Ab der SDK-Version 1.0.6 löst /negotiate den Fehler 413 Payload Too Large aus, wenn das generierte Zugriffstoken größer als 4 K ist.

Lösung

Standardmäßig werden Ansprüche von context.User.Claims beim Generieren des JWT-Zugriffstokens für ASRS(Azure SignalRService) eingeschlossen, sodass die Ansprüche beibehalten werden und von ASRS an den Hub übergeben werden können, wenn der Client eine Verbindung mit dem Hub herstellt.

In einigen Fällen werden context.User.Claims zum Speichern großer Informationsmengen für den App-Server verwendet, von denen die meisten nicht von Hubs, sondern von anderen Komponenten genutzt werden.

Das generierte Zugriffstoken wird über das Netzwerk übermittelt, und bei WebSocket-/SSE-Verbindungen werden Zugriffstoken über Abfragezeichenfolgen übermittelt. Als bewährte Methode wird empfohlen, nur erforderliche Ansprüche vom Client über ASRS an Ihren App-Server zu übergeben, sofern der Hub dies verlangt.

Mit dem ClaimsProvider können Sie die Ansprüche anpassen, die im Zugriffstoken an ASRS übergeben werden.

Für ASP.NET Core:

services.AddSignalR()
        .AddAzureSignalR(options =>
            {
                // pick up necessary claims
                options.ClaimsProvider = context => context.User.Claims.Where(...);
            });

Für ASP.NET:

services.MapAzureSignalR(GetType().FullName, options =>
            {
                // pick up necessary claims
                options.ClaimsProvider = context.Authentication?.User.Claims.Where(...);
            });

Haben Sie Probleme oder Feedback zu dieser Problembehandlung? Teilen Sie es uns mit.

TLS 1.2 erforderlich

Mögliche Fehler:

  • ASP.NET-Fehler „Kein Server verfügbar“#279
  • ASP.NET: „The connection isn't active, data cannot be sent to the service“ („Die Verbindung ist nicht aktiv. Es können keine Daten an den Dienst gesendet werden.“) Fehler Nr. 324
  • „Fehler beim Erstellen der HTTP-Anforderung an https://<API endpoint>. Dies könnte daran liegen, dass das Serverzertifikat nicht richtig mit „HTTP.SYS“ im HTTPS-Fall konfiguriert wurde. Eine andere mögliche Ursache kann eine fehlende Übereinstimmung bei der Sicherheitsbindung zwischen Client und Server sein.“

Tiefere Ursache

Der Azure-Dienst unterstützt aus Sicherheitsgründen nur TLS 1.2. Bei .NET Framework ist es möglich, dass TLS 1.2 nicht das Standardprotokoll darstellt. Daher können keine Serververbindungen mit ASRS hergestellt werden.

Handbuch zur Problembehandlung

  1. Wenn dieser Fehler lokal reproduziert werden kann, deaktivieren Sie Nur eigenen Code, lösen Sie alle CLR-Ausnahmen aus, und debuggen Sie den Anwendungsserver lokal, um zu ermitteln, welche Ausnahme ausgelöst wird.

    • Deaktivieren Sie Nur eigenen Code:

      Uncheck Just My Code

    • Lösen Sie CLR-Ausnahmen aus.

      Throw CLR exceptions

    • Überprüfen Sie, welche Ausnahmen beim Debuggen des serverseitigen App-Codes ausgelöst werden:

      Exception throws

  2. Bei ASP.NET-Dateien können Sie auch folgenden Code der Datei Startup.cs hinzufügen, um eine ausführliche Ablaufverfolgung zu aktivieren und die Fehler aus dem Protokoll anzuzeigen.

    app.MapAzureSignalR(this.GetType().FullName);
// Make sure this switch is called after MapAzureSignalR
GlobalHost.TraceManager.Switch.Level = SourceLevels.Information;

Lösung

Fügen Sie folgenden Code zu „Startup.cs“ hinzu:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Haben Sie Probleme oder Feedback zu dieser Problembehandlung? Teilen Sie es uns mit.

Rückgabe von „400 – Ungültige Anforderung“ für Clientanforderungen

Tiefere Ursache

Überprüfen Sie, ob Ihre Clientanforderung mehrere hub-Abfragezeichenfolgen enthält. hub ist ein persistenter Abfrageparameter, und Fehler 400 wird ausgelöst, wenn der Dienst mehr als einen hub-Parameter in der Abfrage erkennt.

Haben Sie Probleme oder Feedback zu dieser Problembehandlung? Teilen Sie es uns mit.

Rückgabe von „401 – Nicht autorisiert“ für Clientanforderungen

Tiefere Ursache

Der Standardwert für die Lebensdauer von JWT-Token beträgt derzeit eine (1) Stunde.

Dies ist kein Problem, wenn für ASP.NET Core SignalR der WebSocket-Transporttyp verwendet wird.

Bei SSE mit langem Abruf, dem anderen Transporttyp für ASP.NET Core SignalR, bedeutet die Standardlebensdauer, dass die Verbindung gewöhnlich höchstens eine Stunde lang aufrechterhalten werden kann.

Bei ASP.NET SignalR sendet der Client gelegentlich eine /ping-Keepalive-Anforderung an den Dienst. Wenn /ping fehlschlägt, wird die Verbindung vom Client abgebrochen und auch nicht wiederhergestellt. Bei ASP.NET SignalR wird die Verbindung bei allen Transporttypen aufgrund der Standardgültigkeitsdauer des Tokens höchstens eine Stunde lang aufrechterhalten.

Lösung

Aus Sicherheitsgründen wird ein Verlängern von TTL nicht empfohlen. Sie sollten Logik zum Wiederherstellen der Verbindung durch den Client hinzufügen, um die Verbindung bei Fehler 401 wiederherzustellen. Wenn der Client die Verbindung wiederherstellt, wird das JWT-Token bei einer Aushandlung mit dem App-Server nochmals abgerufen, und er empfängt ein verlängertes Token.

Hier erfahren Sie, wie Sie Clientverbindungen wiederherstellen.

Haben Sie Probleme oder Feedback zu dieser Problembehandlung? Teilen Sie es uns mit.

Rückgabe von „404“ für Clientanforderungen

Bei einer dauerhaften SignalR-Verbindung wird zunächst /negotiate für den Azure SignalR Service ausgeführt, und anschließend wird die eigentliche Verbindung mit dem Azure SignalR Service hergestellt.

Handbuch zur Problembehandlung

  • Folgen Sie der Anleitung unter Anzeigen ausgehender Anforderungen vom Client, um die Anforderung des Clients an den Dienst abzurufen.
  • Überprüfen Sie die URL der Anforderung, wenn Fehler 404 auftritt. Wenn die URL auf Ihre Web-App verweist und ähnlich wie {your_web_app}/hubs/{hubName} lautet, überprüfen Sie, ob der Clientparameter SkipNegotiationtrue ist. Der Client erhält eine Umleitungs-URL, wenn er zum ersten Mal in Austausch mit dem App-Server tritt. Der Client darf diesen Austausch beim Verwenden von Azure SignalR nicht überspringen.
  • Ein weiterer Fehler 404 kann auftreten, wenn die Verbindungsanforderung mehr als fünf (5) Sekunden nach dem Aufruf von /negotiate verarbeitet wird. Überprüfen Sie den Zeitstempel der Clientanforderung, und öffnen Sie ein Issue bei einer langsamen Reaktion auf die Anforderung an den Dienst.

Haben Sie Probleme oder Feedback zu dieser Problembehandlung? Teilen Sie es uns mit.

Rückgabe des Fehlers 404 bei einer ASP.NET SignalR-Anforderung zum Wiederherstellen der Verbindung

Wenn bei ASP.NET SignalR die Clientverbindung getrennt wird, wird dreimal die gleiche connectionId zum Wiederherstellen der Verbindung verwendet, bevor die Verbindung beendet wird. /reconnect kann nützlich sein, wenn die Verbindung aufgrund von vorübergehenden Netzwerkproblemen unterbrochen wird, sodass die permanente Verbindung erfolgreich mit /reconnect wiederhergestellt werden kann. Unter anderen Umständen wird die Clientverbindung z. B. getrennt, weil die Verbindung mit dem Routingserver getrennt wurde oder beim SignalR Service interne Fehler wie Neustart, Failover oder Bereitstellung der Instanz aufgetreten sind und die Verbindung daher nicht mehr besteht, sodass /reconnect404 zurückgibt. Dabei handelt es sich um das erwartete Verhalten von /reconnect. Nach drei Wiederholungsversuchen wird die Verbindung beendet. Es wird empfohlen, für den Fall einer getrennten Verbindung Logik zum Wiederherstellen der Verbindung zu implementieren.

Haben Sie Probleme oder Feedback zu dieser Problembehandlung? Teilen Sie es uns mit.

Rückgabe von Fehler 429 (Zu viele Anforderungen) für Clientanforderungen

Es gibt zwei Fälle.

Die Anzahl gleichzeitiger Verbindungen überschreitet den Grenzwert.

Bei Free-Instanzen beträgt der Grenzwert für die Anzahl der gleichzeitigen Verbindungen 20 für Standard Instanzen. Der Grenzwert für die Anzahl gleichzeitiger Verbindungen pro Einheit beträgt 1 K, d. h., Unit100 erlaubt 100 K gleichzeitige Verbindungen.

Die Anzahl der Verbindungen schließt Client- und Serververbindungen mit ein. Hier erfahren Sie, wie Verbindungen gezählt werden.

Zu viele Aushandlungsanforderungen zur gleichen Zeit.

Wir empfehlen, vor dem erneuten Herstellen der Verbindung eine zufällige Verzögerung festzulegen. Beispiele zur Wiederholung finden Sie hier.

Haben Sie Probleme oder Feedback zu dieser Problembehandlung? Teilen Sie es uns mit.

Fehler 500 bei Aushandlung: Der Azure SignalR Service ist noch nicht verbunden. Versuchen Sie es später noch mal.

Tiefere Ursache

Dieser Fehler wird gemeldet, wenn keine Serververbindung mit Azure SignalR Service besteht.

Handbuch zur Problembehandlung

Aktivieren Sie die serverseitige Ablaufverfolgung, um die Fehlerdetails zu ermitteln, wenn der Server versucht, eine Verbindung mit dem Azure SignalR Service herzustellen.

Aktivieren der serverseitigen Protokollierung für ASP.NET Core SignalR

Die serverseitige Protokollierung für ASP.NET Core SignalR ist in ILogger integriert und beruht auf der Protokollierung, die im ASP.NET Core-Framework bereitgestellt wird. Sie können die serverseitige Protokollierung mithilfe von ConfigureLogging aktivieren, wie im folgenden Beispiel gezeigt:

.ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddConsole();
            logging.AddDebug();
        })

Protokollierungskategorien für Azure SignalR beginnen immer mit Microsoft.Azure.SignalR. Wenn Sie detaillierte Protokolle von Azure SignalR aktivieren möchten, konfigurieren Sie die Präfixe in der Datei appsettings.json mit der Ebene Debug, wie hier gezeigt:

{
    "Logging": {
        "LogLevel": {
            ...
            "Microsoft.Azure.SignalR": "Debug",
            ...
        }
    }
}

Aktivieren serverseitiger Ablaufverfolgungen für ASP.NET SignalR

Ab der SDK-Version >= 1.0.0können Sie Ablaufverfolgungen aktivieren, indem Sie in web.config: (Details) Folgendes hinzufügen:

<system.diagnostics>
    <sources>
      <source name="Microsoft.Azure.SignalR" switchName="SignalRSwitch">
        <listeners>
          <add name="ASRS" />
        </listeners>
      </source>
    </sources>
    <!-- Sets the trace verbosity level -->
    <switches>
      <add name="SignalRSwitch" value="Information" />
    </switches>
    <!-- Specifies the trace writer for output -->
    <sharedListeners>
      <add name="ASRS" type="System.Diagnostics.TextWriterTraceListener" initializeData="asrs.log.txt" />
    </sharedListeners>
    <trace autoflush="true" />
  </system.diagnostics>

Haben Sie Probleme oder Feedback zu dieser Problembehandlung? Teilen Sie es uns mit.

Trennen der Clientverbindung

Wenn der Client mit Azure SignalR verbunden ist, kann es vorkommen, dass die permanente Verbindung zwischen dem Client und Azure SignalR aus unterschiedlichen Gründen getrennt wird. In diesem Abschnitt werden verschiedene mögliche Ursachen für die Trennung der Verbindung beschrieben, und es wird erläutert, wie Sie die Ursache ermitteln können.

Mögliche Fehler auf Clientseite

  • The remote party closed the WebSocket connection without completing the close handshake
  • Service timeout. 30000.00ms elapsed without receiving a message from service.
  • {"type":7,"error":"Connection closed with an error."}
  • {"type":7,"error":"Internal server error."}

Tiefere Ursache

Clientverbindungen können unter verschiedenen Umständen getrennt werden:

  • Wenn Hub mit der eingehenden Anforderung Ausnahmen auslöst
  • Wenn die Serververbindung getrennt wird, die für die Clientweiterleitung verwendet wird, finden Sie unten im Abschnitt zum Trennen der Serververbindung weitere Informationen.
  • Wenn ein Problem mit der Netzwerkkonnektivität zwischen dem Client und SignalR Service auftritt
  • Wenn bei SignalR Service interne Fehler auftreten, z. B. bei einem Neustart, einem Failover oder einer Bereitstellung etc.

Handbuch zur Problembehandlung

  1. Öffnen Sie ein serverseitiges App-Protokoll, um festzustellen, ob ein ungewöhnliches Ereignis eingetreten ist.
  2. Überprüfen Sie im serverseitigen Ereignisprotokoll, ob der App-Server neu gestartet wurde.
  3. Erstellen Sie ein Issue mit Angabe des Zeitrahmens, und senden Sie uns den Ressourcennamen per E-Mail zu.

Haben Sie Probleme oder Feedback zu dieser Problembehandlung? Teilen Sie es uns mit.

Anzahl der Clientverbindungen nimmt beständig zu

Dies kann durch eine falsche Verwendung der Clientverbindung verursacht werden. Wenn ein Benutzer vergisst, den SignalR-Client anzuhalten oder zu verwerfen, bleibt die Verbindung geöffnet.

Mögliche Fehler in den SignalR-Metriken im Abschnitt „Überwachung“ des Ressourcenmenüs im Azure-Portal

Clientverbindungen nehmen in den Metriken von Azure SignalR ständig über einen längeren Zeitraum zu.

Client connection increasing constantly

Tiefere Ursache

Für die SignalR-Clientverbindung wird DisposeAsync nie aufgerufen, sodass die Verbindung geöffnet bleibt.

Handbuch zur Problembehandlung

Überprüfen Sie, ob der SignalR-Client nie geschlossen wird.

Lösung

Überprüfen Sie, ob Sie die Verbindung geschlossen haben. Rufen Sie HubConnection.DisposeAsync() manuell auf, wenn Sie die Verbindung nicht mehr benötigen.

Beispiel:

var connection = new HubConnectionBuilder()
	.WithUrl(...)
	.Build();
try
{
	await connection.StartAsync();
	// Do your stuff
	await connection.StopAsync();
}
finally
{
	await connection.DisposeAsync();
}

Unsachgemäße Verwendung der Clientverbindung

Beispiel zu einer Azure-Funktion

Dieses Problem tritt häufig auf, wenn eine SignalR-Clientverbindung in der Azure Functions-Methode hergestellt wird, anstatt sie als statischen Member der Functions-Klasse zu erstellen. Eventuell erwarten Sie nur eine Clientverbindung. Stattdessen erhöht sich die Anzahl der Clientverbindungen in den Metriken ständig. Alle diese Verbindungen werden erst nach dem Neustart von Azure Functions oder Azure SignalR Service getrennt. Dies liegt daran, dass Azure Functions für jede Anforderung eine Clientverbindung herstellt. Wenn Sie die Clientverbindung in der Functions-Methode nicht beenden, behält der Client die Verbindungen mit Azure SignalR Service bei.

Lösung

  • Denken Sie daran, die Clientverbindung zu schließen, wenn Sie SignalR-Clients in einer Azure-Funktion verwenden oder den SignalR-Client als Singleton verwenden.
  • Anstatt SignalR-Clients in Azure-Funktionen zu verwenden, können Sie SignalR-Clients anderweitig erstellen und mithilfe von Azure Functions-Bindungen für den Azure SignalR Service die Aushandlung zwischen Client und Azure SignalR ausführen. Außerdem können Sie die Bindung verwenden, um Nachrichten zu senden. Beispiele für die Clientaushandlung und das Senden von Nachrichten finden Sie hier. Weitere Informationen finden Sie hier.
  • Wenn Sie SignalR-Clients in einer Azure-Funktion verwenden, gibt es für Ihr Szenario möglicherweise eine besser geeignete Architektur. Überprüfen Sie, ob Sie eine ordnungsgemäße serverlose Architektur konzipiert haben. Weitere Informationen finden Sie unter Erstellen von serverlosen Echtzeitanwendungen mit SignalR Service-Bindungen für Azure Functions.

Haben Sie Probleme oder Feedback zu dieser Problembehandlung? Teilen Sie es uns mit.

Trennen der Serververbindung

Wenn der App-Server gestartet wird, wird das Azure SDK im Hintergrund gestartet, um Serververbindungen mit dem Remote-Azure SignalR Service zu initiieren. Wie in den ausführlichen Informationen zu Azure SignalR Service beschrieben, leitet Azure SignalR eingehenden Clientdatenverkehr an diese Serververbindungen weiter. Nachdem eine Serververbindung getrennt wurde, werden alle Clientverbindungen, die er behandelt, ebenfalls geschlossen.

Da es sich bei den Verbindungen zwischen App-Server und SignalR Service um persistente Verbindungen handelt, treten möglicherweise Netzwerkverbindungsprobleme auf. Im Server-SDK ist die Strategie Verbindungen immer wiederherstellen für Serververbindungen definiert. Als bewährte Methode wird Benutzer*innen auch empfohlen, Clients Logik zum fortlaufenden Wiederherstellen von Verbindungen mit einer zufälligen Verzögerungszeit hinzuzufügen, um zahlreiche gleichzeitige Anforderungen an den Server zu vermeiden.

In regelmäßigen Abständen werden neue Versionen von Azure SignalR Service veröffentlicht. Azure-weites Patchen oder Upgrades führen gelegentlich zu Unterbrechung bei abhängigen Diensten. Diese Ereignisse können kurze Dienstunterbrechungen zur Folge haben. Solange die Clientseite über einen Mechanismus zum Trennen und Wiederherstellen der Verbindung verfügt, sind die Auswirkungen jedoch minimal – wie bei jeder clientseitig verursachten Verbindungstrennung/-wiederherstellung.

In diesem Abschnitt werden verschiedene mögliche Ursachen für die Trennung der Serververbindung beschrieben, und es wird erläutert, wie Sie die Ursache ermitteln können.

Mögliche Fehler auf Serverseite

  • [Error]Connection "..." to the service was dropped
  • The remote party closed the WebSocket connection without completing the close handshake
  • Service timeout. 30000.00ms elapsed without receiving a message from service.

Tiefere Ursache

Die Serverdienstverbindung wird von ASRS(Azure SignalRService) geschlossen.

Bei einem Pingtimeout ist dies möglicherweise auf eine hohe CPU-Auslastung oder einen blockierten Threadpool auf Serverseite zurückzuführen.

In SDK 1.6.0 wurde für ASP.NET SignalR ein bekanntes Problem behoben. Führen Sie für das SDK ein Upgrade auf die neueste Version aus.

Blockierung des Threadpools

Wenn der Server blockiert ist, bedeutet das, dass von Threads keine Nachrichten verarbeitet werden. Kein Thread reagiert mit einer bestimmten Methode.

Dieses Szenario wird normalerweise durch Async-over-Sync oder durch Task.Result/Task.Wait() in asynchronen Methoden verursacht.

Weitere Informationen finden Sie unter Best Practices zur Leistung in ASP.NET Core.

Weitere Informationen finden Sie unter Blockierung des Threadpools.

Erkennen einer Threadpoolblockierung

Überprüfen Sie die Threadanzahl. Gehen Sie wie folgt vor, wenn derzeit keine Spitzen vorhanden sind:

  • Wenn Sie Azure App Service verwenden, überprüfen Sie die Threadanzahl in Metriken. Überprüfen Sie die Aggregation Max:

    Screenshot of the Max thread count pane in Azure App Service.

  • Wenn Sie .NET Framework verwenden, finden Sie Metriken im Systemmonitor auf der Server-VM.

  • Wenn Sie .NET Core in einem Container verwenden, finden Sie unter Sammeln von Diagnosen in Containern entsprechende Informationen.

Sie können Threadpoolblockierungen auch mithilfe von Code erkennen:

public class ThreadPoolStarvationDetector : EventListener
{
    private const int EventIdForThreadPoolWorkerThreadAdjustmentAdjustment = 55;
    private const uint ReasonForStarvation = 6;

    private readonly ILogger<ThreadPoolStarvationDetector> _logger;

    public ThreadPoolStarvationDetector(ILogger<ThreadPoolStarvationDetector> logger)
    {
        _logger = logger;
    }

    protected override void OnEventSourceCreated(EventSource eventSource)
    {
        if (eventSource.Name == "Microsoft-Windows-DotNETRuntime")
        {
            EnableEvents(eventSource, EventLevel.Informational, EventKeywords.All);
        }
    }

    protected override void OnEventWritten(EventWrittenEventArgs eventData)
    {
        // See: https://learn.microsoft.com/dotnet/framework/performance/thread-pool-etw-events#threadpoolworkerthreadadjustmentadjustment
        if (eventData.EventId == EventIdForThreadPoolWorkerThreadAdjustmentAdjustment &&
            eventData.Payload[2] as uint? == ReasonForStarvation)
        {
            _logger.LogWarning("Thread pool starvation detected!");
        }
    }
}

Fügen Sie Ihrem Dienst Folgendes hinzu:

service.AddSingleton<ThreadPoolStarvationDetector>();

Überprüfen Sie dann Ihr Protokoll, wenn die Serververbindung durch ein Pingtimeout getrennt wird.

Finden der Grundursache einer Threadpoolblockierung

So finden Sie die Grundursache einer Threadpoolblockierung:

  • Erstellen Sie ein Arbeitsspeicherabbild, und analysieren Sie anschließend die Aufrufliste. Weitere Informationen finden Sie unter Collect and analyze memory dumps (Sammeln und Analysieren von Arbeitsspeicherabbildern).
  • Verwenden Sie clrmd zum Erstellen eines Arbeitsspeicherabbilds, wenn eine Threadpoolblockierung erkannt wird. Protokollieren Sie anschließend die Aufrufliste.

Handbuch zur Problembehandlung

  1. Öffnen Sie das serverseitige App-Protokoll, um festzustellen, ob ein ungewöhnliches Ereignis eingetreten ist.
  2. Überprüfen Sie im serverseitigen Ereignisprotokoll, ob der App-Server neu gestartet wurde.
  3. Erstellen Sie ein Issue. Geben Sie den Zeitrahmen an, und senden Sie uns den Ressourcennamen per E-Mail.

Haben Sie Probleme oder Feedback zu dieser Problembehandlung? Teilen Sie es uns mit.

Tipps

Anzeigen ausgehender Anforderungen vom Client

Als Beispiel wird hier ASP.NET Core verwendet (ASP.NET ist vergleichbar):

  • Aus dem Browser: Nehmen Sie Chrome als Beispiel. Sie können F12 verwenden, um das Konsolenfenster zu öffnen und zur Registerkarte Netzwerk zu wechseln. Möglicherweise müssen Sie die Seite mit F5 aktualisieren, um das Netzwerk von Anfang an zu erfassen.

    Chrome View Network

  • Im C#-Client:

    Sie können lokalen Webdatenverkehr mit Fiddler anzeigen. WebSocket-Datenverkehr wird ab Fiddler 4.5 unterstützt.

    Fiddler View Network

Wiederherstellen der Clientverbindung

Im Folgenden finden Sie Beispielcode mit Logik zum Wiederherstellen von Verbindungen mit der Strategie Verbindung immer wiederherstellen:

Haben Sie Probleme oder Feedback zu dieser Problembehandlung? Teilen Sie es uns mit.

Nächste Schritte

In diesem Leitfaden wurde beschrieben, wie Sie häufig auftretende Probleme behandeln. Außerdem konnten Sie sich über eher allgemeine Verfahren zur Problembehandlung informieren.

Behandeln von Konnektivitätsproblemen und von Problemen bei der Nachrichtenübermittlung