☰

Nginx-Konfiguration für Reverse-Proxying von UDP-Datenverkehr (Minecraft-App) – 90 Nachrichten zu lang

tag-icon • tag-icon nginx udp
Nginx-Konfiguration für Reverse-Proxying von UDP-Datenverkehr (Minecraft-App) – 90 Nachrichten zu lang

Versuch, UDP-Verkehr als Proxy zu leiten. nginx meldet keinen Fehler bezüglich der Konfiguration. Der Client stellt bis zur Hälfte eine Verbindung her (er sagt, er könne den Endserver erreichen), aber dann bleibt die Verbindung hängen und wird schließlich mit einer Zeitüberschreitung beendet.

nginx-Version: 1.21.3 Betriebssystem: Ubuntu 18.04

nginx.conf:

worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

worker_rlimit_nofile 30000;

events {
    worker_connections 30000;
    multi_accept on;
}

stream{
server {
    listen       *:4800-4899 udp;
    proxy_pass   217.178.x.x:$server_port;
}
}

Fehlerprotokoll:

2213#2213: *3 recv() failed (90: Message too long) while proxying and reading from upstream, udp client: 49.98.x.x, server: 66.42.x.x:4801, upstream: "217.178.x.x:4801", bytes from/to client:1464/0, bytes from/to upstream:0/1464

49.98.xx: Client-IP 66.42.xx: Proxy-IP 217.178.xx: Endserver-IP

IP-A-Ausgabe

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever

2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 56:00:03:95:cc:59 brd ff:ff:ff:ff:ff:ff
    inet 66.42.x.x/23 brd 66.42.x.255 scope global dynamic enp1s0
       valid_lft 57402sec preferred_lft 57402sec
    inet6 fe80::5400:3ff:fe95:[xxx]/64 scope link 
       valid_lft forever preferred_lft forever

Irgendeine Idee, was falsch ist? Sieht irgendjemand ein Problem in der Konfiguration?

Danke

Antwort1

Möglicherweise hängt das Problem „90: Nachricht zu lang“ mit dem EMSGSIZE-Fehler ( If the message is too long to pass atomically through the underlying protocol, the error EMSGSIZE is returned, and the message is not transmitted) zusammen. In diesem Fall können Sie versuchen, es zu lösen, indem Sie die Größe des Socket-Sendepuffers erhöhen. Die folgenden Parameter haben Standardwerte:

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

Die aktuellen Werte auf Ihrem Server können Sie mit dem folgenden Befehl überprüfen:

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

Zum Test können Sie mit folgendem Befehl beispielsweise folgende Werte einstellen:

sysctl -w net.core.wmem_default = 9999999
sysctl -w net.core.wmem_max = 9999999
echo "net.core.wmem_default = 9999999
net.core.wmem_max = 9999999 ">> /etc/sysctl.conf

Überprüfen Sie als Nächstes, ob sie korrekt angewendet wurden (jetzt muss es 9999999 sein):

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

Und versuchen Sie, das Problem zu reproduzieren.

verwandte Informationen