Проксі-змінні Transmission впливають на HTTP-трекери, а не на піри
Відокремте HTTP-запити трекерів Transmission від з'єднань із пірами та DHT, перш ніж вважати змінений маршрут трекера завантаженням через проксі.
Трекер відповідає після того, як ви надасте Transmission проксі-URL, складений з даних вашого сервісу або запису в списку проксі. Це може виправити доступ до трекера, не змінюючи того, куди прямує пір-трафік торента.
Документація Transmission щодо змінних середовища визначає libcurl як компонент, що виконує HTTP- і HTTPS-анонси та збирання даних трекерів. Проксі-змінні, які використовує ця бібліотека, налаштовують ці запити. Вони не є глобальною мережевою політикою для всієї програми.
| Операція | Що встановлює налаштування tracker-proxy |
|---|---|
| HTTP- або HTTPS-запит трекера | Запит libcurl може вибрати налаштований проксі |
| З'єднання з піром | Жодного висновку з цього результату трекера |
| DHT або інша UDP-активність | Жодного висновку з цього результату трекера |
Торент може містити кілька механізмів виявлення. Тому отримання списку пірів через проксі сумісне з тим, що подальші з'єднання виходять через звичайний інтерфейс.
Якщо ви запускаєте демон, його середовище також належить цьому сервісу, а не терміналу, що виконує команду віддаленого керування. На інсталяціях на основі systemd задайте змінні в сервісі демона. Передача правильної змінної правильному процесу необхідна для задокументованого шляху libcurl; це все одно не розширює межі цього шляху.
Описуйте результат окремо для кожної операції. «Запит трекера використав проксі» — корисно. «Мережева ідентичність завантаження змінилася» потребує доказів щодо пір-з'єднань, які передають дані.