starred/bambuddy-maziggy-1

Fork 0

mirror of https://github.com/maziggy/bambuddy.git synced 2026-05-09 08:25:54 +02:00

[GH-ISSUE #537] [Bug]: Virtual Printer not reachable behind reverse proxy #344

New issue

Closed

opened 2026-05-07 00:09:02 +02:00 by BreizhHardware · 6 comments

BreizhHardware commented

2026-05-07 00:09:02 +02:00

Owner

Originally created by @Cutyno on GitHub (Feb 27, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/537

Originally assigned to: @maziggy on GitHub.

Bug Description

If run in a docker compose setup with a reverse proxy the virtual printer is not reachable from BambuStudio. It is not possible to set the bambuddy container to network_host.

Expected Behavior

It should be possible to input the real ip address as the binding address of the host system (not only detect the ip address of the docker container).

Steps to Reproduce

Setup bambuddy beind a nginx reverse proxy
Expose all ports according to https://wiki.bambuddy.cool/features/virtual-printer/#docker-macos-windows except for "NET_BIND_SERVICE" capability
Create a virtual printer in Bambuddy according to the documentation
Try to connect to the virtual printer with BambuStudio

Printer Model

X1E

Bambuddy Version

0.1.2 - 0.2.1

Printer Firmware Version

01.02.00.00

Installation Method

Docker

Operating System

Linux (Ubuntu/Debian)

Relevant Logs / Support Package

Screenshots

No response

Additional Context

No response

Checklist

I have searched existing issues to ensure this bug hasn't already been reported
I am using the latest version of Bambuddy
My printer is set to LAN Only mode
My printer has Developer Mode enabled

Originally created by @Cutyno on GitHub (Feb 27, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/537 Originally assigned to: @maziggy on GitHub. ### Bug Description If run in a docker compose setup with a reverse proxy the virtual printer is not reachable from BambuStudio. It is not possible to set the bambuddy container to network_host. ### Expected Behavior It should be possible to input the real ip address as the binding address of the host system (not only detect the ip address of the docker container). ### Steps to Reproduce 1. Setup bambuddy beind a nginx reverse proxy 2. Expose all ports according to https://wiki.bambuddy.cool/features/virtual-printer/#docker-macos-windows except for "NET_BIND_SERVICE" capability 3. Create a virtual printer in Bambuddy according to the documentation 4. Try to connect to the virtual printer with BambuStudio ### Printer Model X1E ### Bambuddy Version 0.1.2 - 0.2.1 ### Printer Firmware Version 01.02.00.00 ### Installation Method Docker ### Operating System Linux (Ubuntu/Debian) ### Relevant Logs / Support Package ```shell ``` ### Screenshots _No response_ ### Additional Context _No response_ ### Checklist - [x] I have searched existing issues to ensure this bug hasn't already been reported - [x] I am using the latest version of Bambuddy - [x] My printer is set to LAN Only mode - [x] My printer has Developer Mode enabled

BreizhHardware

2026-05-07 00:09:02 +02:00

closed this issue
added the
bug
label

BreizhHardware commented

2026-05-07 00:09:03 +02:00

Author

Owner

@maziggy commented on GitHub (Feb 28, 2026):

This is unfortunately a fundamental Docker networking limitation rather than a Bambuddy bug.

The virtual printer relies on SSDP multicast (UDP) for BambuStudio to discover it. Multicast traffic does not traverse Docker bridge networks, so even with all TCP ports forwarded, BambuStudio can never discover the virtual printer. There's also no way to manually add a LAN printer by IP in BambuStudio — it relies entirely on SSDP.

Working configurations:

network_mode: host (recommended) — The container shares the host's network stack, so SSDP multicast works natively. Your nginx reverse proxy for the web UI can still run separately (either as another container or on the host) and proxy to localhost:8000. The reverse proxy is only needed for HTTP — the virtual printer services (MQTT/FTP/SSDP) are direct connections that can't be reverse-proxied anyway.
macvlan network — Gives the container a real IP on your LAN, so multicast works. More complex to set up but avoids network_mode: host.

Would either of these work for your setup? If you're using network_mode: host for other containers and that's the conflict, you could split Bambuddy into its own compose file with network_mode: host while keeping nginx in a separate bridge network.

@maziggy commented on GitHub (Feb 28, 2026): This is unfortunately a fundamental Docker networking limitation rather than a Bambuddy bug. The virtual printer relies on SSDP multicast (UDP) for BambuStudio to discover it. Multicast traffic does not traverse Docker bridge networks, so even with all TCP ports forwarded, BambuStudio can never discover the virtual printer. There's also no way to manually add a LAN printer by IP in BambuStudio — it relies entirely on SSDP. Working configurations: 1. network_mode: host (recommended) — The container shares the host's network stack, so SSDP multicast works natively. Your nginx reverse proxy for the web UI can still run separately (either as another container or on the host) and proxy to localhost:8000. The reverse proxy is only needed for HTTP — the virtual printer services (MQTT/FTP/SSDP) are direct connections that can't be reverse-proxied anyway. 2. macvlan network — Gives the container a real IP on your LAN, so multicast works. More complex to set up but avoids network_mode: host. Would either of these work for your setup? If you're using network_mode: host for other containers and that's the conflict, you could split Bambuddy into its own compose file with network_mode: host while keeping nginx in a separate bridge network.

BreizhHardware commented

2026-05-07 00:09:03 +02:00

Author

Owner

@nerdspar commented on GitHub (Mar 1, 2026):

I've been using macvlan with Bambuddy itself behind a reverse proxy and multiple virtual printers for a few weeks and it's been working great. I second that recommendation.

@nerdspar commented on GitHub (Mar 1, 2026): I've been using macvlan with Bambuddy itself behind a reverse proxy and multiple virtual printers for a few weeks and it's been working great. I second that recommendation.

BreizhHardware commented

2026-05-07 00:09:03 +02:00

Author

Owner

@maziggy commented on GitHub (Mar 1, 2026):

Are you willing to contribute and write down a howto?

@maziggy commented on GitHub (Mar 1, 2026): Are you willing to contribute and write down a howto?

BreizhHardware commented

2026-05-07 00:09:03 +02:00

Author

Owner

@nerdspar commented on GitHub (Mar 2, 2026):

I guess I lied. I thought I had it working with macvlans as I had messed with it a bit but ended up just using the two NICs on my host for my two printers instead. I'm trying to get it working but running into issues. Will update if I get things figured out.

@nerdspar commented on GitHub (Mar 2, 2026): I guess I lied. I thought I had it working with macvlans as I had messed with it a bit but ended up just using the two NICs on my host for my two printers instead. I'm trying to get it working but running into issues. Will update if I get things figured out.

BreizhHardware commented

2026-05-07 00:09:03 +02:00

Author

Owner

@Cutyno commented on GitHub (Mar 2, 2026):

This is unfortunately a fundamental Docker networking limitation rather than a Bambuddy bug.

The virtual printer relies on SSDP multicast (UDP) for BambuStudio to discover it. Multicast traffic does not traverse Docker bridge networks, so even with all TCP ports forwarded, BambuStudio can never discover the virtual printer. There's also no way to manually add a LAN printer by IP in BambuStudio — it relies entirely on SSDP.

Working configurations:

network_mode: host (recommended) — The container shares the host's network stack, so SSDP multicast works natively. Your nginx reverse proxy for the web UI can still run separately (either as another container or on the host) and proxy to localhost:8000. The reverse proxy is only needed for HTTP — the virtual printer services (MQTT/FTP/SSDP) are direct connections that can't be reverse-proxied anyway.

macvlan network — Gives the container a real IP on your LAN, so multicast works. More complex to set up but avoids network_mode: host.

Would either of these work for your setup? If you're using network_mode: host for other containers and that's the conflict, you could split Bambuddy into its own compose file with network_mode: host while keeping nginx in a separate bridge network.

Thanks for the clarification! I don't see why neither of those solutions wouldn't work. Let me test it first.

@Cutyno commented on GitHub (Mar 2, 2026): > This is unfortunately a fundamental Docker networking limitation rather than a Bambuddy bug. > > The virtual printer relies on SSDP multicast (UDP) for BambuStudio to discover it. Multicast traffic does not traverse Docker bridge networks, so even with all TCP ports forwarded, BambuStudio can never discover the virtual printer. There's also no way to manually add a LAN printer by IP in BambuStudio — it relies entirely on SSDP. > > Working configurations: > > 1. network_mode: host (recommended) — The container shares the host's network stack, so SSDP multicast works natively. Your nginx reverse proxy for the web UI can still run separately (either as another container or on the host) and proxy to localhost:8000. The reverse proxy is only needed for HTTP — the virtual printer services (MQTT/FTP/SSDP) are direct connections that can't be reverse-proxied anyway. > 2. macvlan network — Gives the container a real IP on your LAN, so multicast works. More complex to set up but avoids network_mode: host. > > Would either of these work for your setup? If you're using network_mode: host for other containers and that's the conflict, you could split Bambuddy into its own compose file with network_mode: host while keeping nginx in a separate bridge network. Thanks for the clarification! I don't see why neither of those solutions wouldn't work. Let me test it first.

BreizhHardware commented

2026-05-07 00:09:04 +02:00

Author

Owner

@Cutyno commented on GitHub (Mar 3, 2026):

Ok I figured out another problem. The first problems stands. I configured the reverse proxy to use TLS certificates and publishing the http port to the host network makes this kinda pointless.

But I don't need a solution for this anymore. As I just figured out my PC and the server running bambuddy are in different VLANs and SSDP are blocked from traversing. I guess there will be no fix due to the limitation originates from BambuLab and not Bambuddy.

Anyway! Thanks for this great project. Keep the good work up!

@Cutyno commented on GitHub (Mar 3, 2026): Ok I figured out another problem. The first problems stands. I configured the reverse proxy to use TLS certificates and publishing the http port to the host network makes this kinda pointless. But I don't need a solution for this anymore. As I just figured out my PC and the server running bambuddy are in different VLANs and SSDP are blocked from traversing. I guess there will be no fix due to the limitation originates from BambuLab and not Bambuddy. Anyway! Thanks for this great project. Keep the good work up!

BreizhHardware referenced this issue

2026-05-07 00:15:27 +02:00

[PR #344] [CLOSED] New Feature: Confirm Part Removal #1008