U
/u/NeoForge_
Guest
Running a Pterodactyl/Wings setup (VPS, Docker) with a Velocity proxy (4.1.0-SNAPSHOT) and a lobby server, both in separate containers on the same host.
The problem: every time the lobby container restarts (crash, manual restart, or a host reboot that changes container start order), Velocity starts throwing this:
Turns out the internal Docker bridge IP for the lobby container changes because Docker assigns bridge IPs dynamically based on start order (basically DHCP-like behavior), and
I tried pointing Velocity at the host's public IP + published port instead (
ort works fine (
Haven't yet tested resolving the lobby by its Wings/container UUID as an internal DNS name instead of IP, which seems like the "correct" fix, but wanted to ask first:
How do you all handle backend server addressing in velocity.toml when running Pterodactyl/Wings, so it survives container restarts without manual IP updates?
(Disclaimer: used Claude to help debug/diagnose this and draft this post, but the setup, logs, and testing are all mine — just want a sanity check from people who've actually dealt with this in production.)
submitted by /u/NeoForge_
[link] [comments]
Continue reading...
The problem: every time the lobby container restarts (crash, manual restart, or a host reboot that changes container start order), Velocity starts throwing this:
io.netty.channel.AbstractChannel$AnnotatedConnectException: finishConnect(..) failed with error(-111): Connection refused: /172.18.0.x:25571 Turns out the internal Docker bridge IP for the lobby container changes because Docker assigns bridge IPs dynamically based on start order (basically DHCP-like behavior), and
velocity.toml obviously still has the old IP hardcoded.I tried pointing Velocity at the host's public IP + published port instead (
x.x.x.x:25571) as a "stable" workaround. Connecting from the host itself to that public IPort works fine (curl -v telnet://...), but Velocity (running inside its own container) still gets the same connection refused — looks like a hairpin NAT issue specific to container → host-public-IP traffic, not a host-level networking problem.Haven't yet tested resolving the lobby by its Wings/container UUID as an internal DNS name instead of IP, which seems like the "correct" fix, but wanted to ask first:
How do you all handle backend server addressing in velocity.toml when running Pterodactyl/Wings, so it survives container restarts without manual IP updates?
(Disclaimer: used Claude to help debug/diagnose this and draft this post, but the setup, logs, and testing are all mine — just want a sanity check from people who've actually dealt with this in production.)
submitted by /u/NeoForge_
[link] [comments]
Continue reading...