Владимир Дубровин

смотря что именно надо, например

auth iponly
allow *
parent 1000 socks5+ 127.0.0.1 порт логин пароль
proxy

или

auth useronly
allow *
parent 1000 socks5+ 127.0.0.1 порт * *
proxy

если надо прокинуть логин/пароль переданные в http прокси в socks

Убедитесь, что клиент настроен разрешать имена через socks, если клиент делает запрос с IPv4 адресом. а не с именем хоста - он не попадет в IPv6

Убери /127.0.0.1, если RADIUS не на локальном интерфейсе, то со 127.0.0.1 ты туда не попадешь.
Версия 3proxy какая?

Так сделать не получится, потому что работает это следующим образом
1. HTTPS прокси не видит URI запроса, т.к. он идет внутри TLS соединения. Это можно решить через SSLPlugin, но все клиенты должны доверять сертификату прокси
2. socks5 не видит URI запроса, он ничего не знает про прикладной протокол, это можно решить перенаправлением в локальный http прокси
3. URI в 3proxy не участвует в установке исходящего соединения, это функции обратного прокси типа nginx + как минимум для https на момент когда будет приходить URI соединение с родительским сервером уже будет установлено - это одним 3proxy решить не получится

Если нужно именно SOCKSv5, то можно domain.com парентить из 3proxy в nginx, на нем терминировать TLS (если речь про https) и проксипасить по урлам

allow * * aa.site.ru,bb.site.ru,cc.site.ru 80,443
parent 1000 tcp dev.aa.site.ru 0
allow *
proxy

вместо aa.site.ru,bb.site.ru,cc.site.ru можно указать ip, тогда будет перенаправляться все что резолвится в этот ip

Можно использовать внешнюю авторизацию - RADIUS/Windows/PAM

Браузеры не поддерживают парольную авторизацию в SOCKS. Используйте для браузеров HTTP прокси или устанавливайте локальный прокси без авторизации который будет форвардить запросы в родительский с авторизацией.

Например в 3proxy можно использовать примерно такую конфигурацию для прокси обслуживающего входящие подключения:

users ...
auth ...

allow *
parent 1000 out.proxy.address1 port login password
proxy -p1111

flush
allow *
parent 1000 out.proxy.address2 port login password
proxy -p2222

запросы по порту 1111 будет перенаправляться через родительский прокси out.proxy.address1
запросы по порту 2222 будет перенаправляться через родительский прокси out.proxy.address2

В "классическом" варианте, access token это короткоживущий токен для доступа к конечному ресурсу, refresh token это долгоживущий токен, который служит для получения access token'а, он отправляется не на конечный ресурс, а на сервер OAuth. Если вам надо сделать разовое действие, то refresh не требуется, при авторизации вы сразу получаете access token и refresh token и можете не хранить refresh. Если вам надо делать регулярные действия (например проверять не пришли ли новые письма или не появились ли новые события календаря), то access token через некоторое время протухает, и чтобы получить новый надо его обновить, получив от OAuth сервера новый access с помощью refresh token'а

Есть два совершенно разных типа FTP прокси - FTP over HTTP и "нативный" FTP прокси,
1. FTP over HTTP раньше использовался исключительно для браузеров, на входе принимал HTTP запрос типа GET ftp://.... и отдавал или оглавление каталога в виде HTML или запрошенный файл, сейчас браузеры FTP не поддерживают и это практически вымерло. Обычно такая функция реализовалась в HTTP-проксях. В 3proxy такая функциональность поддержанва в http proxy (proxy).
2. Нативный FTP прокси - FTP не предусматривает наличие прокси, поэтому такие серверы не стандартны. Обычно с точки зрения клиента работает как FTP сервер, но поддерживает или дополнительную команду OPEN или ищет имя сервера назначения в имени юзера, т.е. чтобы попасть пользователем vasya на сервер example.com вы подключетесь по FTP к прокси-серверу, но в имени юзера пишется vasya@example.com (прелесть в том, что такой прокси можно использовать даже с клиентами не поддерживающими FTP прокси) или перед прочими FTP-командами дается команда CONNECT example.com (для этого клиент должен поддерживать FTP прокси). В 3proxy такая функцииональность поддержана в ftppr.

allow *
parent 1000 http proxy1 port1 login1 password1
proxy -p10001 -i127.0.0.1
flush
allow *
parent 1000 http proxy2 port2 login2 password2
proxy -p10002 -i127.0.0.1
flush
allow *
parent 1000 socks5+ proxy3 port3 login3 password3
proxy -p10003 -i127.0.0.1
...

На прокси сервер обычно передается имя хоста, далее прокси разрешает его в IPv4 и/или IPv6 адрес. При этом возможны разные варианты - прокси может разрешать имена только в IPv4, только в IPv6, сначала в IPv6 а при отсутствии IPv6 адреса у имени в IPv4 или наоборот, или случайно выбирать IPv4/IPv6 адреса из списка доступных адресов.
Проверить можно так как вы и проверяете - обратитесь через прокси к хосту у которого есть и IPv4 и IPv6 адреса и посмотрите с какого адреса (IPv4 или IPv6) пришел прокси. Или просто спросите у поддержки сервиса прокси стратегию разрешения имен.
Если вам строго надо IPv4 или IPv6 вы можете разрешать имя на своей стороне а прокси передавать IPv4 или IPv6 адрес.

Настройте 2 IP адреса из разных сетей и двумя шлюзами, дальше два варианта:
1. Настроить source routing в системе с разных IP через разные маршрутизаторы, в 3proxy запустить два прокси с параметрами типа
proxy -p1111 -e1.1.1.1
proxy -p2222 -e2.2.2.2
2. если не хочется/не можется настроить сорс роутинг, то запускать 3proxy от рута без chroot в конфиге с биндингом к интерфейсу, те конфигурацией типа

proxy -p1111 -e1.1.1.1 -DeИНТЕРФЕЙС1
proxy -p2222 -e2.2.2.2 -DeИНТЕРФЕЙС2

IP адрес сейчас обычно относят к хрупким признакам и не используют его напрямую для блокировок аномальной активности. Его можно использовать, например, в рейтлимитерах с пониманием что это делает различные переборы немного дороже, но не снимает проблему полностью.
Подробно о том как делать антифрод вам вряд ли кто-то расскажет Для обнаружения именно аномальной активности, используются различные фингерпринты клиента и поведенческие анализаторы. Основная цель обычно это не избавиться полностью, а сделать ее экономически невыгодной, и капча тут может работать, если правильно и против правильных векторов использовать, где она действительно работает. Если регистрация на вашем сайте приносит несколько баксов которые можно вывести или монетизировать без идентификации личности - вас вряд ли что-то спасет от фродовых регистраций, поэтому антифрод должен начинаться с бизнес-логики и возможно вы смотрите не в ту сторону.