4.1 KiB
4.1 KiB
Docker Network Mode Fix Report
Date: 2026-01-21
Action: Changed NPMplus Docker container from host to bridge network mode
Fix Applied
Changes Made
- ✅ Stopped Docker container:
npmplus - ✅ Removed container (preserving data volumes)
- ✅ Recreated container with bridge network mode:
- Network:
bridge(changed fromhost) - Port mappings:
-p 80:80 -p 443:443 -p 81:81 - Data volumes: Preserved (
/opt/npmplus:/data) - Image:
zoeyvid/npmplus:latest
- Network:
Results
- ✅ Container running: Up and healthy
- ✅ Network mode: Changed to
bridge - ✅ Ports listening: 80 and 443 are listening via docker-proxy
- ✅ NPMplus → VMID 5000: Working (HTTP 200)
- ⚠️ 192.168.11.166:80: Still not accessible (HTTP 000)
- ✅ 192.168.11.167:80: Accessible (HTTP 308)
Current Status
What's Working
- Docker container: Running with bridge network
- Port mappings: Docker-proxy is listening on 0.0.0.0:80/443
- Internal connectivity: NPMplus can proxy to VMID 5000
- Secondary IP: 192.168.11.167 is accessible
What's Not Working
- Primary IP: 192.168.11.166 is still not accessible
- This may be a routing issue
- Docker bridge network creates its own network namespace
- Ports are mapped but may not be accessible on primary interface
Analysis
Docker Bridge Network Behavior
When using bridge network mode:
- Docker creates a virtual network interface (
docker0) - Container gets an IP on the Docker bridge network (typically 172.17.0.0/16)
- Port mappings forward traffic from host ports to container ports
- The host ports (80, 443) should be accessible on all host interfaces
Why 192.168.11.166 May Not Work
Possible reasons:
-
Docker port mapping binds to specific interface
- May need to check if docker-proxy is binding correctly
- May need to verify iptables rules
-
LXC container network namespace
- Docker bridge network inside LXC may have routing issues
- May need to check container routing table
-
Timing issue
- NPMplus may need more time to fully start
- Docker-proxy may need time to establish connections
Next Steps
Option A: Verify Docker Port Binding
Check if docker-proxy is binding to all interfaces:
ssh root@r630-01
pct exec 10233 -- ss -tlnp | grep docker-proxy
pct exec 10233 -- iptables -t nat -L -n -v | grep 80
Option B: Test from Different Sources
# From Proxmox host
ssh root@r630-01
curl -I http://192.168.11.166:80
# From container itself
pct exec 10233 -- curl -I http://192.168.11.166:80
pct exec 10233 -- curl -I http://localhost:80
Option C: Check Docker Network Configuration
ssh root@r630-01
pct exec 10233 -- docker network inspect bridge
pct exec 10233 -- docker inspect npmplus --format "{{.NetworkSettings.Networks}}"
Option D: Use 192.168.11.167 (Current Working Solution)
Since 192.168.11.167 is working:
- Update UDM Pro port forwarding to use 192.168.11.167
- This is the quickest solution
- Both IPs are on the same container, so functionality is identical
Recommendation
Immediate Solution: Use 192.168.11.167 (already working)
Long-term Investigation:
- Check Docker network routing inside LXC container
- Verify docker-proxy binding behavior
- May need to adjust Docker daemon configuration
Verification Commands
# Test NPMplus accessibility
curl -I http://192.168.11.167:80
curl -I https://192.168.11.167:443 -k
# Test NPMplus dashboard
curl -I https://192.168.11.167:81 -k
# Test proxy functionality
curl -H "Host: explorer.d-bis.org" http://192.168.11.167:80
# Test external access (after updating UDM Pro)
curl -I https://explorer.d-bis.org
Summary
Status: ✅ Docker network mode fixed (host → bridge)
Current State:
- Container using bridge network mode
- Ports mapped correctly
- 192.168.11.167 is accessible
- 192.168.11.166 needs further investigation
Action: Update UDM Pro port forwarding to use 192.168.11.167 (working IP)
Next Step: Update UDM Pro port forwarding destination to 192.168.11.167