Ang mga proxy variable ng Transmission ay nakakaapekto sa HTTP tracker, hindi sa peer
Ihiwalay ang HTTP tracker na kahilingan ng Transmission mula sa peer connection at DHT bago ituring na proxy download ang binagong ruta ng tracker.
Sumasagot ang tracker pagkatapos mong bigyan ang Transmission ng proxy URL na ginawa mula sa detalye ng iyong serbisyo o sa isang entry sa isang listahan ng proxy. Maaaring maayos nito ang pag-access sa tracker nang hindi binabago kung saan napupunta ang peer traffic ng torrent.
Tinutukoy ng dokumentasyon ng environment variable ng Transmission ang libcurl bilang bahaging gumagawa ng HTTP at HTTPS tracker announce at scrape. Ang mga proxy variable na ginagamit ng library na iyon ay nag-aayos ng mga kahilingang iyon. Hindi ito pandaigdigang patakaran sa network para sa buong application.
| Operasyon | Ano ang itinatatag ng setting ng tracker-proxy |
|---|---|
| HTTP o HTTPS na kahilingan sa tracker | Maaaring piliin ng kahilingan ng libcurl ang naka-configure na proxy |
| Koneksyon sa isang peer | Walang konklusyon mula sa resultang iyon ng tracker |
| DHT o iba pang aktibidad na UDP | Walang konklusyon mula sa resultang iyon ng tracker |
Maaaring maglaman ang isang torrent ng ilang mekanismo ng pagtuklas. Kaya naman, ang pagtanggap ng listahan ng peer sa pamamagitan ng proxy ay tugma sa mga koneksyong lumalabas sa ordinaryong interface mamaya.
Kung pinapatakbo mo ang daemon, pag-aari din ng serbisyong iyon ang kapaligiran nito, hindi ng terminal na nagpapatakbo ng remote-control command. Sa mga instalasyong nakabatay sa systemd, itakda ang mga variable sa serbisyo ng daemon. Kailangan ang tamang variable sa tamang proseso para sa dokumentadong landas ng libcurl; hindi pa rin nito pinalalawak ang saklaw ng landas na iyon.
Ilarawan ang resulta bawat operasyon. Kapaki-pakinabang ang “Ginamit ng kahilingan sa tracker ang proxy.” Ang “Nagbago ang network identity ng download” ay nangangailangan ng ebidensya tungkol sa mga peer connection na nagdadala ng data.