Saúde do proxy: que sitio web e que operación probaches?
Separa a alcanzabilidade xeral do proxy das fallas específicas do destino cando mantés un conxunto de proxies reutilizable.
Un proxy obtén a túa páxina de comprobación de IP e falla na API que necesita a túa aplicación. Chamalo «san» ou «morto» perde o dato máis útil: as dúas peticións eran distintas.
Comeza cun rexistro de todo o transporte para o punto final. Podes chegar ao seu oínte e completar a negociación de proxy necesaria? Mantén as observacións específicas do destino xunto a ese rexistro en lugar de sobrescribilo.
| Observación | Ámbito a investigar |
|---|---|
| O oínte do proxy rexeita conexións | O punto final e a ruta ata el |
| O proxy denega un porto de destino | A operación permitida para ese destino |
| Un sitio web devolve un erro de conta | A aplicación de destino e as credenciais |
| As respostas grandes atascan, as pequenas rematan | A carga de transferencia e a política de tempo de espera |
Unha resposta HTTP pode establecer que unha ruta de petición devolveu algo e, aínda así, seguir sendo inutilizable para a aplicación. Mantén o éxito do transporte, o estado HTTP e o contido esperado como resultados separados.
Se un destino falla repetidamente, pausa ou investiga esa parella de punto final e destino. Desactivar o proxy para cada tarefa non relacionada pode desperdiciar capacidade útil. Á inversa, unha falla de conexión global non debería quedar oculta tras o rexistro illado dun só sitio web.
Unha clave de saúde práctica pode incluír o identificador do proxy, o servizo de destino e o tipo de operación. Evita usar o URL completo que leva credenciais ou cada ruta única de recurso como unha clave que medra sen parar. Agrupa só onde a agrupación fai unha predición significativa sobre a próxima petición.
O propósito son mellores probas de enrutamento, non unha colección maior de insignias verdes. Un resultado de saúde debería dicir que se intentou, cando e que estabeleceu realmente.