Waarom 'n instaanbediener jou blaaier-IP verander, maar nie ander toepassings nie
'n HTTP-instaanbedienerinstelling in jou blaaier of Wi-Fi stuur nie outomaties elke toepassing en protokol deur die gekose IP nie.
'n Veranderde IP in jou blaaier beskryf daardie blaaierversoek. Ander toepassings kan hul direkte roete behou, want instaanbedienerinstellings is besonderhede wat elke kliënt moet ondersteun en gebruik.
| Waar die instaanbediener gestel is | Wat dit gewoonlik beheer |
|---|---|
| Firefox se handinstellings | Versoeke wat Firefox ondersteun. |
| Die stelsel se HTTP-instaanbediener | Toepassings wat daardie opstelling lees en ondersteun. |
| 'n Toepassing se HTTP- of SOCKS-opsies | Die verkeer wat deur daardie toepassing se implementering gedek word. |
| 'n Wi-Fi-netwerk se instaanbediener | Kliënte wat dié instelling op daardie netwerk gebruik. |
'n Speletjie of 'n stemoproep kan verkeer buite die HTTP-pad gebruik; 'n toepassing wat direkte sokke oopmaak, kan die stelselinstaanbediener heeltemal ignoreer. Selfs SOCKS5 het implementeringsondersteuning nodig: die protokol definieer UDP-assosiasie, maar Chromium se ingeboude SOCKS5 dek TCP-URL-versoeke, nie 'n algemene UDP-aflos nie.
Vind die ander toepassing se gedokumenteerde instaanbedienerkoppelvlak en pas die protokol daarby. As dit geen koppelvlak bied nie, sal herhaalde verandering van die stelsel se HTTP-eindpunt dit waarskynlik nie instel nie. Verifieer 'n versoek uit daardie toepassing deur sy diagnostiek of 'n bestemming wat jy beheer; curl kan 'n eindpunt valideer, maar nie 'n ander toepassing se roete bevestig nie.
Kontroleer weer ná begin of netwerkveranderinge. 'n Proses kan instellings behou wat by aanvang gelees is, en 'n foon wat na mobiele data oorskakel laat Wi-Fi-spesifieke opstelling agter. As jy toestelwye roetering nodig het, kies 'n meganisme wat daarvoor ontwerp is; een kliënt se HTTP-instelling kan dit nie bewerkstellig nie.