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

Тут есть путаница - есть HTTPS прокси в настройках соединения - это обычный HTTP прокси, без TLS между браузером и прокси, который используется для https трафика, и есть прокси задаваемый через URL (например https://proxy.host:3128) или через тип HTTPS в WPAD - здесь HTTPS vs HTTP как раз означает наличие TLS между браузером и прокси

* в качестве логина/пароля родительского прокси
можно использовать auth useronly (чтобы требовалось имя пользователя в запросе) и для socks дополнительно можно -u2 чтобы он не предлагал доступ без авторизации

auth useronly
allow *
parent 1000 тип хост порт * *
socks

Когда вы подключаетесь через прокси у вас tcp fingerprint роутера, можете посмотреть фингерпринты например здесь
https://browserleaks.com/ip и такие фингерпринты могут блокироваться сервером, т.к. обычно с ними ходят боты/DDoS но практически никогда не ходят пользователи. hcaptcha проверять фингерпринты несомненно умеет.

https://www.amocrm.ru/support/email/connecting_a_d...
AmoCRM должен выдать вам DKIM запись которую надо прописать в вашем DNS. Ее надо прописать дополнительно к DKIM который выдал вам mail, т.е. должно быть 2 DKIM-записи с разными селекторами - частью до _domainkey. DKIM и SPF надо прописывать для каждого почтового сервера через который вы шлете почту.

Если вы уже прописали записи - обратитесь в поддержку AmoCRM

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

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

или

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

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

Считайте что WebAssembly это отдельная платформа (не Windows, не Linux и не что-то еще), использовать Windows DLL в ней нельзя, если только вы не напишете / не портируете туда эмулятор Windows, использовать динамическую линковку можно, но между модулями написанными под wasm.

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

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

Есть OAuth 2.0 - это протокол авторизации между клиентским приложением и сервером с ресурсами

Нет, не так. В OAuth2 участвуют минимум 3 стороны - ресурсный сервер, клиент и сервер авторизации. Обычно OAuth используется в ситуациях когда имеется несколько ресурсных серверов и надо иметь единую точку авторизации. В этой схеме логины/пароли/рефреш-токены видит только сервер авторизации, клиент использует рефреш-токены для получения короткоживущих аксесс токенов с нужными скопами к ресурсным серверам. Компрометация одного из ресурсных серверов при правильной организации доступа не скомпрометирует доступ клиента к другим ресурсным серверам.

Убери /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

В C используетсяvoid *, обратиться по нему без преобразования типа не получится

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

На практике в современных браузерах этот вектор в XSS не эксплуатируется из-за URI энкода. Последними популярными браузерами где этот вектор был эксплуатируем были IE 6/7, они не URI-енкодили GET-параметры при редиректе. Однако вставка URI без HTML-енкода в любом случае является ошибкой, даже если не приводит к XSS, например по стандарту должен HTML-енкодиться символ &, который может присутствовать в урлах.

Если старый сервер не отдает старые NS записи зоны, то проблем возникнуть не должно и достаточно все менять на cloudflare, но обычно рекомендуют полностью снести зону со старого сервера чтобы избежать ситуации когда резолверы будут рефрешить записи из старой зоны.

Скорей всего, есть фоновое приложение которое начинает работать при простое и съедает ресурсы, посмотрите по диспетчеру задач. Это может быть и что-то безобидное, например бекап по сети или синхронизация облачного диска, а может быть и какой-нибудь троян с майнером/прокси/DDoS, в последнем случае есть шанс его по диспетчеру задач не увидеть. Судя по собранной диагностике выжирается у вас скорей всего сетевой канал до провайдера.