gbanyan/GB-Traefik
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Document host networking rationale

Browse Source
This commit is contained in:
Gbanyan
2025-11-12 15:13:47 +08:00
parent 1f572927a1
commit a58f5a3406
1 changed files with 9 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
README.md
View File

@@ -94,3 +94,12 @@ PS: Because I access my traefik dashboard through my local network. I commented
- 2025.4.21 Fix the trusted IP settings; later replaced by an internal updater instead of the traefik-plugin-cloudflare. - 2025.4.21 Fix the trusted IP settings; later replaced by an internal updater instead of the traefik-plugin-cloudflare.
- 2025.4.18 Add Souin HTTP Cache Middleware (in feature branch, not merge into main) - 2025.4.18 Add Souin HTTP Cache Middleware (in feature branch, not merge into main)
- 2025.4.18 Temp disable the compression middleware. It has MIME type bugs. - 2025.4.18 Temp disable the compression middleware. It has MIME type bugs.
## Notes on Host Networking
Traefik currently runs with `network_mode: host` so it can bind directly to both `10.0.0.225` (public) and `192.168.50.4` (internal) entrypoints. Moving back to bridge mode would break that dual-IP isolation because Docker cannot publish the same container port on two different host interfaces. Host networking also means:
- Traefik reaches app containers like any other host process, ignoring `traefik.docker.network` labels.
- Linux handles firewalling/routing between the two interfaces; Docker’s conntrack optimizations aren’t used.
If you ever want to switch to bridge networking, you’d need either separate Traefik instances (one per subnet) or an external L4 proxy in front of a single Traefik that listens on generic `:80/:443` ports. For now the host-mode trade-off is intentional to keep the internal/external split simple.