Прозрачный прокси TCMinerProxy

Прозрачный прокси

Прозрачный прокси передает входящие данные на настроенный целевой адрес без разбора содержимого. Он не определяет протокол майнера, wallet или worker name, а текущий узел TCMinerProxy не применяет fee-логику, replacement-правила и полную статистику, которым нужен разбор протокола.

Иными словами, это прозрачный jump-путь: какие данные пришли, такие данные отправляются дальше.

Отличие От Обычной Пересылки

Обычная пересылка чаще всего использует адрес пула как целевой адрес. Майнеры подключаются к forwarding-порту TCMinerProxy, а трафик уходит в upstream-пул. Это подходит, когда нужно просто собрать вход майнеров на одном порту.

Прозрачный прокси чаще нужен между узлами TCMinerProxy. Его целевым адресом может быть не пул, а TMS-порт нижнего TCMinerProxy. Первый сервер TCMinerProxy не расшифровывает, не распаковывает и не преобразует TMS-поток; он только передает локальный зашифрованный или сжатый поток на следующий сервер.

Когда Использовать

Используйте прозрачный прокси, если на локальной площадке уже применяется TMS, HAProxy или другой инструмент шифрования, сжатия или пересылки, а трафик должен пройти через один TCMinerProxy jump-сервер к другому TCMinerProxy, который уже подключается к пулу.

Типовая цепочка:

Локальный TMS -> TCMinerProxy transparent proxy jump server -> TMS-порт нижнего TCMinerProxy -> Пул

Без прозрачного прокси первому TCMinerProxy обычно пришлось бы разобрать или расшифровать локальный TMS-трафик, а затем снова упаковать его в протокол, который ожидает нижний TCMinerProxy. Это сложнее в настройке и добавляет еще один этап шифрования/расшифровки или сжатия, что увеличивает нагрузку CPU и риск задержек.

Схема Настройки

Главная идея: jump-сервер только прозрачно передает байты, а TMS-протокол обрабатывает нижний TCMinerProxy.

Настройки Порта Jump-Сервера

При создании proxy-порта на jump TCMinerProxy:

1. В качестве listening protocol выберите TP или transparent proxy.
2. Укажите listening port, к которому будет подключаться локальный TMS.
3. В primary pool address укажите TMS-порт нижнего TCMinerProxy, например next-tcminerproxy.example.com:9000.
4. В качестве target pool protocol выберите TLS/SSL.
5. Fee wallets, wallet replacement, worker replacement и другие функции, основанные на разборе протокола, оставьте отключенными или не учитывайте.

Важно: target protocol на jump-сервере должен быть TLS/SSL. TMS-порт нижнего TCMinerProxy использует зашифрованный канал, поэтому jump-сервер должен передавать локальный TMS-поток без изменений к этой TLS/SSL-цели.

Совпадение TMS-Протоколов

Протокол локального TMS должен совпадать с протоколом TMS-порта на нижнем TCMinerProxy.

Jump-порт работает только как прозрачный прокси. Он не преобразует TMS2 в TMS3 и не преобразует TMS3(Zstd) в другой протокол. Версия протокола, compression level, super compression и связанные параметры все равно должны совпадать между локальным TMS и нижним TCMinerProxy.

Проверка

1. Убедитесь, что TMS-порт нижнего TCMinerProxy запущен и нормально подключается к пулу.
2. Запустите transparent proxy порт на jump TCMinerProxy.
3. В локальном TMS замените remote address на адрес jump-сервера и порт transparent proxy.
4. Проверьте, что локальный TMS подключился, а счетчик соединений на jump-сервере вырос.
5. Проверьте miners, hashrate и connection logs на нижнем TCMinerProxy.
6. Убедитесь, что worker появился в конечном пуле.

Transparent proxy порт не показывает полную статистику wallet, worker, hashrate и fee. Для бизнес-данных ориентируйтесь на нижний TCMinerProxy и конечный пул.

Частые Ошибки