Proxyvariabelen van Transmission raken HTTP-trackers, niet peers
Scheid de HTTP-trackerverzoeken van Transmission van peer-verbindingen en DHT voordat u een gewijzigde trackerroute als een download via een proxy beschouwt.
Een tracker antwoordt nadat u Transmission een proxy-URL hebt gegeven die is opgebouwd uit de gegevens van uw dienst of een vermelding in een proxylijst. Dat kan de trackertoegang herstellen zonder te veranderen waar het peerverkeer van de torrent heen gaat.
De documentatie over omgevingsvariabelen van Transmission noemt libcurl als het onderdeel dat HTTP- en HTTPS-trackeraankondigingen en -scrapes uitvoert. De proxyvariabelen die die bibliotheek gebruikt, passen die verzoeken aan. Ze zijn geen wereldwijd netwerkbeleid voor de hele toepassing.
| Bewerking | Wat de tracker-proxyinstelling vastlegt |
|---|---|
| HTTP- of HTTPS-trackerverzoek | Het libcurl-verzoek kan de geconfigureerde proxy kiezen |
| Verbinding met een peer | Geen conclusie uit dat trackeresultaat |
| DHT of andere UDP-activiteit | Geen conclusie uit dat trackeresultaat |
Een torrent kan meerdere ontdekkingsmechanismen bevatten. Een peerlijst via een proxy ontvangen is daarom verenigbaar met latere verbindingen die via een gewone interface naar buiten gaan.
Als u de daemon draait, hoort zijn omgeving ook bij die dienst, niet bij de terminal die een opdracht voor afstandsbediening uitvoert. Op systemd-installaties stelt u de variabelen in op de daemondienst. De juiste variabele aan het juiste proces geven is nodig voor het gedocumenteerde libcurl-pad; het verruimt de reikwijdte van dat pad nog steeds niet.
Beschrijf een resultaat per bewerking. ‘Het trackerverzoek gebruikte de proxy’ is nuttig. ‘De netwerkidentiteit van de download is veranderd’ vraagt bewijs over de peer-verbindingen die de gegevens dragen.