Transmissions proxyvariabler påverkar HTTP-trackers, inte peers
Separera Transmissions HTTP-förfrågningar till trackers från peeranslutningar och DHT innan du behandlar en ändrad tracker-väg som en proxad nedladdning.
En tracker svarar efter att du gett Transmission en proxy-URL byggd från din tjänsts uppgifter eller en post i en proxylista. Det kan åtgärda trackeråtkomst utan att ändra vart torrentens peertrafik tar vägen.
Transmissions dokumentation om miljövariabler pekar ut libcurl som komponenten som gör HTTP- och HTTPS-annonseringar och scrapes mot trackers. Proxyvariabler som det biblioteket använder anpassar dessa förfrågningar. De är inte en global nätverkspolicy för hela programmet.
| Åtgärd | Vad inställningen för tracker-proxy fastställer |
|---|---|
| HTTP- eller HTTPS-förfrågan till tracker | Libcurl-förfrågan kan välja den konfigurerade proxyn |
| Anslutning till en peer | Ingen slutsats från det trackerresultatet |
| DHT eller annan UDP-aktivitet | Ingen slutsats från det trackerresultatet |
En torrent kan innehålla flera upptäcktsmekanismer. Att få en peerlista via en proxy är därför förenligt med att senare anslutningar går ut via ett vanligt gränssnitt.
Om du kör daemonen tillhör dess miljö också den tjänsten, inte terminalen som kör ett fjärrstyrningskommando. På systemd-baserade installationer, ange variablerna på daemontjänsten. Att ge rätt variabel till rätt process är nödvändigt för den dokumenterade libcurl-vägen; det utökar fortfarande inte den vägens omfattning.
Beskriv ett resultat per åtgärd. ”Trackerförfrågan använde proxyn” är användbart. ”Nedladdningens nätverksidentitet ändrades” kräver bevis om peeranslutningarna som bär data.