Fixing Docker Network Connectivity Between Containers | Generated by AI

Home 2026.03

Sure, let me break it down properly.

🦞 The Problem: Uptime Kuma Can’t Reach LibreChat

How Docker Networking Works Here

Each docker-compose stack creates its own isolated network by default. When you deploy LibreChat, Docker creates librechat_default. When you deploy Uptime Kuma, Docker creates uptime-kuma_default. These networks are isolated from each other — containers on one can’t talk to containers on the other by name.

Why 192.168.1.36 Doesn’t Work From Inside a Container

Your host has the IP 192.168.1.36 on the LAN. But Docker containers have their own network namespaces. When Uptime Kuma tries to reach http://192.168.1.36:3080/, the traffic has to:

  1. Exit the container → hit the Docker bridge
  2. Route through the host’s network stack → find 192.168.1.36
  3. Hit the host’s firewall/port forwarding rules → reach the Docker proxy on port 3080

That chain can break in many places (iptables, Docker’s FORWARD policy, extra_hosts, host firewall). In your case, it just times out.

What We Know

Check Result
curl http://192.168.1.36:3080/ from host ✅ 200
wget http://LibreChat:3080/ from Uptime Kuma ❌ Can’t resolve LibreChat
http.get('http://192.168.1.36:3080/') from Uptime Kuma ❌ ETIMEDOUT
Docker networks uptime-kuma_default ≠ librechat_default

The Fix (Three Options)

Option 1 — Quick & Dirty (what I just ran)

docker network connect librechat_default uptime-kuma

This attaches Uptime Kuma to LibreChat’s network as a second network. Works immediately, but doesn’t survive container restarts — you’d need to re-run it after every docker-compose up.

Option 2 — Permanent: Add the external network to Uptime Kuma’s compose file

Edit /home/lzw/uptime-kuma/docker-compose.yml to use LibreChat’s existing network instead of creating its own:

services:
  uptime-kuma:
    # ... existing config ...
    networks:
      - librechat_default

networks:
  librechat_default:
    external: true   # ← Don't create it, use the existing one

This makes it survive restarts. The trade-off: Uptime Kuma is now fully on LibreChat’s network (shares the same subnet).

Option 3 — Permanent & Separate: Keep both networks, link them

Add librechat_default as a second network in the Uptime Kuma compose:

services:
  uptime-kuma:
    # ... existing config ...
    networks:
      - uptime-kuma_default
      - librechat_default

networks:
  uptime-kuma_default:   # ← Keep Kuma's own network
  librechat_default:
    external: true        # ← Also attach to LibreChat's

This is the cleanest — Uptime Kuma keeps its own network but can also reach LibreChat containers by name.

After the Network Fix

Update the monitor URL in Uptime Kuma from:

http://192.168.1.36:3080/

to:

http://LibreChat:3080/

This uses Docker’s internal DNS to resolve the container name directly — faster, more reliable, and works even if the host IP changes.

Want me to go ahead and apply Option 3 to your compose file? That’s the one I’d pick.

Back Donate