Cette page explique comment diagnostiquer et résoudre les erreurs courantes liées aux règles et aux stratégies de proxy Web sécurisé.
Aucune stratégie n'est associée à la passerelle Secure Web Proxy
Si votre passerelle Secure Web Proxy n'est associée à aucune règle, tout le trafic HTTP et HTTPS sortant est bloqué, ce qui entraîne des erreurs 403 Forbidden ou des réinitialisations de connexion. Cela se produit, car Secure Web Proxy suit une stratégie deny-all par défaut et que la passerelle n'a aucune règle associée pour évaluer ou autoriser les requêtes. Par conséquent, tout le trafic sortant est bloqué jusqu'à ce que vous créiez une règle allow explicite.
Pour résoudre ce problème, créez une règle de sécurité avec les règles appropriées et associez-les à votre passerelle Secure Web Proxy.
Échecs de création de règles parallèles
La création parallèle de règles de Secure Web Proxy (ajout simultané de plusieurs règles) n'est pas prise en charge et peut entraîner des erreurs 409 Conflict ou Resource busy. Pour vous assurer que votre instance de Secure Web Proxy est correctement déployée, vous devez créer les règles de manière séquentielle (les unes après les autres).
Les connexions se terminent après cinq minutes d'inactivité.
Si les applications clientes subissent des réinitialisations de connexion ou des arrêts inattendus sur des connexions persistantes (telles que des sessions de streaming, des connexions de base de données ou des WebSockets) via Secure Web Proxy, il est possible que ces connexions dépassent le délai d'inactivité du flux.
Le proxy Web sécurisé applique un délai d'inactivité du flux par défaut et non configurable (stream_idle_timeout) de cinq minutes (300 secondes). Si le client et la destination n'échangent pas de données pendant cinq minutes, Secure Web Proxy réinitialise ou ferme la connexion.
Pour éviter que les connexions ne se ferment en raison de l'inactivité du flux, configurez votre application cliente ou de backend pour qu'elle envoie des sondes de maintien en vie ou des signaux de présence (tels que des signaux de maintien en vie TCP, des trames ping HTTP ou des requêtes d'état périodiques) à des intervalles inférieurs à cinq minutes. Par exemple, vous pouvez envoyer une vérification toutes les une à deux minutes.