En side med et URL-felt er en webapplikation. Når du indtaster en destination der, beder du den applikation om at hente og vise indhold. Det er en anden ordning end at bede browseren om at bruge en HTTP- eller SOCKS-proxy.

Med en indbygget proxyindstilling behandler browseren stadig destinations-URL'en som webstedet. I en traditionel webformular-proxy leveres den synlige side via proxyapplikationens eget URL-skema og oprindelse. Tjenesten kan omskrive links, scripts, headere eller cookies for at få navigationen til at fortsætte.

AdfærdHvorfor forskellen betyder noget
Kontroller af samme oprindelseBrowseren vurderer den oprindelse, den faktisk indlæste
Cookies og omdirigeringerDomæne-, sti- og sikker-kontekst-adfærd skal passe til de viste URL'er
Scripts der bygger nye URL'erAnmodninger kan undslippe en simpel omskrivning af links
Vedvarende forbindelser eller WebSocketsProxyapplikationen kræver eksplicit kompatibel håndtering

Det forklarer et velkendt resultat: en simpel artikel indlæses, men en dokumenteditor eller et loginforløb fejler. Fejlen behøver ikke betyde, at destinationen afviser tjenestens exit-IP. Mellemleddet kan være ude af stand til at bevare applikationens antagelser om URL'er og browsersikkerhed.

Skeln også mellem, hvor TLS slutter. En tjeneste, der henter og genudgiver destinationsindhold, står i en anden tillidsmæssig position end et almindeligt CONNECT-relay, der bærer en krypteret session. At se HTTPS på proxy-webstedets egen adresse etablerer ikke en end-to-end TLS-forbindelse fra browseren til det oprindelige websted.

Hvis målet er almindelig browsing gennem en anden udgang, vælg et HTTP- eller SOCKS-endpoint fra din tjeneste eller fra en proxyliste, og brug en understøttet indbygget proxykonfiguration, fx Firefox' forbindelsesindstillinger. Det bevarer normalt mere af browserens normale destinationssemantik. Et websted med URL-felt kan stadig være en bevidst valgt applikation, men det bør ikke fremstilles som den samme grænseflade med mindre opsætning.

Relaterede artikler