Un proxy preia pagina dvs. de verificare IP și eșuează pe API-ul de care are nevoie aplicația dvs. Numindu-l „sănătos” sau „mort” se pierde cel mai util fapt: cele două cereri erau diferite.

Începeți cu o înregistrare la nivel de transport pentru punctul final. Puteți ajunge la listener-ul său și finaliza negocierea proxy necesară? Păstrați observațiile specifice destinației lângă acea înregistrare în loc să o suprascrieți.

ObservațieDomeniu de investigat
Listener-ul proxy refuză conexiunilePunctul final și ruta către el
Proxy-ul refuză un port de destinațieOperațiunea permisă pentru acea destinație
Un site web returnează o eroare de contAplicația de destinație și credențialele
Răspunsurile mari se blochează, cele mici se terminăSarcina de transfer și politica de timeout

Un răspuns HTTP poate stabili că o cale de cerere a returnat ceva, rămânând totuși inutilizabilă pentru aplicație. Păstrați succesul transportului, starea HTTP și conținutul așteptat ca rezultate separate.

Dacă o destinație eșuează repetat, întrerupeți sau investigați acea pereche punct final-destinație. Dezactivarea proxy-ului pentru fiecare sarcină fără legătură poate irosi capacitate utilă. Invers, o defecțiune globală de conexiune nu ar trebui să rămână ascunsă în spatele înregistrării izolate a unui singur site web.

O cheie de sănătate practică poate include identificatorul proxy-ului, serviciul destinației și tipul operațiunii. Evitați utilizarea întregului URL care poartă credențiale sau a fiecărei căi unice de resursă ca cheie care crește continuu. Grupați doar acolo unde gruparea oferă o predicție semnificativă despre următoarea cerere.

Scopul este o dovadă mai bună de rutare, nu o colecție mai mare de insigne verzi. Un rezultat de sănătate ar trebui să spună ce s-a încercat, când și ce a stabilit de fapt.

Articole similare