Конфигурация nginx для обратного проксирования UDP-трафика (приложение Minecraft) — слишком длинное сообщение 90

Пытаюсь проксировать udp трафик. nginx не выдает никаких ошибок в конфигурации. Клиент подключается на полпути (он говорит, что может достичь конечного сервера), но затем соединение зависает и в конечном итоге закрывается по тайм-ауту.

версия нгинкс: 1.21.3 ОС: Убунту 18.04

nginx.conf:

рабочие_процессы авто;
pid /run/nginx.pid;
включить /etc/nginx/modules-enabled/*.conf;

worker_rlimit_nofile 30000;

События {
    worker_connections 30000;
    мульти_принять;
}

транслировать{
сервер {
    слушать *:4800-4899 udp;
    proxy_pass 217.178.x.x:$server_port;
}
}

журнал ошибок:

2213#2213: *3 recv() не удалось (90: сообщение слишком длинное) при проксировании и чтении из восходящего потока, клиент udp: 49.98.x.x, сервер: 66.42.x.x:4801, восходящий поток: "217.178.x.x:4801", байты от/к клиенту: 1464/0, байт от/к восходящему потоку: 0/1464

49.98.x.x: IP-адрес клиента 66.42.x.x: IP-адрес прокси-сервера 217.178.x.x: IP-адрес конечного сервера

IP выход

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    ссылка/петля 00:00:00:00:00:00 брд 00:00:00:00:00:00
    инет 127.0.0.1/8 область хоста lo
       valid_lft навсегда
    inet6 :: 1/128 узел области видимости 
       valid_lft навсегда

2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    ссылка/эфир 56:00:03:95:cc:59 brd ff:ff:ff:ff:ff:ff
    inet 66.42.x.x/23 brd 66.42.x.255 область глобальная динамическая enp1s0
       valid_lft 57402sec предпочитаемый_lft 57402sec
    inet6 fe80::5400:3ff:fe95:[xxx]/64 ссылка на область действия 
       valid_lft навсегда

Есть идеи, что случилось? Может ли кто-нибудь увидеть какие-либо проблемы в конфигурации?

Спасибо

Возможно, проблема "90: Слишком длинное сообщение" может быть связана с ошибкой EMSGSIZE (Если сообщение слишком длинное для атомарного прохождения через базовый протокол, возвращается ошибка EMSGSIZE, и сообщение не передается.), и в этом случае вы можете попытаться решить эту проблему, увеличив размер буфера отправки сокета. Следующие параметры имеют стандартные значения:

net.core.wmem_default = 212992
net.core.wmem_max = 212992

Текущие значения на вашем сервере можно проверить командой:

sysctl-a | grep "net.core.wmem"

Для теста с помощью следующей команды можно установить, например, следующие значения:

sysctl -w net.core.wmem_default = 9999999
sysctl -w net.core.wmem_max = 9999999
эхо "net.core.wmem_default = 9999999
net.core.wmem_max = 9999999 ">> /etc/sysctl.conf

Далее проверяем, правильно ли они были применены (теперь должно быть 9999999):

sysctl-a | grep "net.core.wmem"

И попробуй воспроизвести проблему.