Запускаю wireguard на сервере и подключаюсь с клиента в обычной стандартной конфигурации и в итоге скорость интернета через туннель печальная, но если создать на сервере правило маршрутизации wg в tun от sing-box (freedom outbound), то скорость интернета через туннель на клиенте возрастает почти до максимальной.
Я так понимаю при таком конфиге сам сервер начинает устанавливать tcp соединения, а не просто гнать трафик по маршруту, и скорость возрастает из-за tcp congestion control (bbr). Так вот есть ли какие-то более дешевые способы сделать похожее через wireguard? Нагрузка на цп сильно возрастает из-за singbox, может есть какой-то похожий софт?

Попробуйте в конфигах wg добавить MTU = 1492. и вообще потестить на уменьшение mtu.

1492 это выход за рамки, если на интернет интерфейсе (или роутере) стоит mtu 1500, то максимальный mtu внутри ipv4 wg не может быть выше 1440 (который у меня и стоит, уменьшение только снижает скорость как и положено)

у меня “чистый” wg вообще не требует манипуляций с mtu. а вот его обертки в разные штуки постоянно ругаются на оверсайсз. при этом скорость падает раза в 2-3. уменьшение mtu в этих случаях повышает скорость, как и положено ) ваш случай просто мне показался очень похожем на проблемы с mtu )

по дефолту в wg mtu 1420 который и не требует манипуляций на большинстве сетей

ничего другого похожего не нашел и решил оставить sing-box, но часто появляется плавающий баг: новые соединения перестают устанавливаться (curl зависает на trying…), в логах системы и sing-box при этом ничего необычного. попробую поставить сокс сервер и tun2socks вместо одного sing-box

upd: hev-socks5-tunnel и hev-socks5-server вместе не дают нужного эффекта, как будто системный tcp или его настройки не используются. hev-socks5-tunnel и sing-box с socks в итоге пинг на wg клиентах становится 2x, системный tcp используется но скорость все равно ужасна. Походу придётся смириться или поверх wg пускать уже какой-то другой протокол (hysteria? от wg отказываться не хочу, уж очень удобен)

tpws zapret’а, по идее, может работать в таком режиме. Он использует splice для проксирования сокетов, должно создавать минимум нагрузки на CPU.

попробовал tpws, tcptp-booster, xray. Использовал iptables redirect, и еще сделал небольшой бенч time curl https://1.1.1.1/cdn-cgi/trace, который грубо говоря выдает время загрузки сайта

прямое подключение: бенч выдает 330ms real

tpws: маленькое потребление цп. Иногда в dmesg вижу сообщения о syn flood, решением будет запуск нескольких tpws и load balance через iptables -m statistic. На моей системе есть неопределенный баг с 100% потреблением цп если использовать iptables tproxy. бенч выдает 430ms real

tcptp-booster: маленькое потребление цп (спорно), бенч выдает 530ms real.

xray: большое потребление цп, по умолчанию нет защиты от петли (при обычном tcp подключении к порту прокси начинает потреблять 100% цп), бенч выдает 330ms

sing-box с tun отбросил из-за неопределенного бага, из-за которого иногда не устанавливались новые соединения (curl рандомно зависал)

решил остановиться на xray для постоянного использования

для гугл поиска: udp vpn tcp bbr boost