Proxyrotation på tværs af anmodninger, forbindelser og sessioner
Kontroller, hvad en roterende proxytjeneste faktisk roterer, før du føjer Connection: close til hver applikationsanmodning.
En anden anmodning gennem samme gateway kan helt legitimt bruge samme offentlige IP. Kontroller, hvilken levetid tjenesten bruger til sin rotation:
| Rotationsenhed | Hvad der skal sammenlignes |
|---|---|
| Anmodning | Den næste applikationshandling og dens observerede udgang |
| Forbindelse | Om klienten genbrugte en kompatibel forbindelse eller åbnede en anden |
| Udbyderens session | Det dokumenterede input til klæbrig session og dets levetid |
Connection: close er ikke en universel gateway-instruktion. For HTTPS inde i CONNECT rejser webstedets anmodningsheader inde i destinationens TLS. Den fortæller ikke den ydre proxy, hvilken offentlig IP der skal tildeles. HTTP/1.1's forbindelsesspecifikke semantik kan heller ikke føres uændret over i enhver HTTP-version eller transport.
Hvis en dokumenteret tjeneste pr. forbindelse kræver en ny forbindelse, skal du bruge den livscyklusstyring, klienten understøtter, og medregne gentagne omkostninger til TCP/TLS-opsætning. Hvis rotationen følger en udbyderession, kan en genopkobling bevare både den session og dens udgang.
Notér anmodnings-id, endepunkt, den relevante sessionsnøgle og den kilde, der iagttages ved destinationen, hver for sig. Lukning af en forbindelse fastslår kun den livscyklushændelse; verificér den udgang, der er valgt til den næste handling, mod tjenestens faktiske rotationskontrakt.