Sonarr/Radarr unable to connect to Deluge under Gluetun?

[Jay2645]

Hey, all. I've been running Deluge through a SOCKS5 proxy and trackers would randomly disconnect me, which was driving me nuts. I found this Reddit post which directed me towards Gluetun, which works like a charm!

I originally followed the docker-compose of that comment pretty much verbatim, swapping in my own containers for theirs. I could see that Deluge was working through the proxy... but for some reason, Sonarr/Radarr weren't connecting to Deluge properly anymore. They always failed with The operation has timed out: 'http://192.168.86.222:8112/json'. Notably, I can access the Deluge web UI through http://192.168.86.222:8112... but I get a 405 error if I navigate to http://192.168.86.222:8112/json.

I put them all under the same network, which didn't solve the issue -- and on top of that, I couldn't connect to Sonarr/Radarr via http anymore from my web browser (http://192.168.86.222:8989 would give ERR_CONNECTION_REFUSED)! When these containers are outside the gluetun network, everything is fine... which makes me think that there's some setting blocking them? I'm not sure how to fix it. I'm also not sure why the Deluge web UI would work, but not the Sonarr/Radarr web UIs.

Here's my docker-compose:

services:
  gluetun:
    image: qmcgaw/gluetun
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    network_mode: bridge
    ports:
      - 8888:8888/tcp # HTTP proxy
      - 8388:8388/tcp # Shadowsocks
      - 8388:8388/udp # Shadowsocks
      - 8000:8000/tcp # Built-in HTTP control server
      - 9117:9117 # Jackett
      - 6060:8080 # sabnzbd
      - 9090:9090 # sabnzbd
      - 8112:8112 # Deluge
      - 6881:6881/tcp # Deluge
      - 6881:6881/udp # Deluge 
      - 8090:8090 # Mylarr
      - 8686:8686 # Lidarr
      - 7878:7878 # Radarr
      - 8989:8989 # Sonarr
    volumes:
      - /share/Container/config/gluetun:/gluetun
    environment:
      - PUID=0
      - PGID=0
      - VPNSP=nordvpn
      - OPENVPN_USER=<secret>
      - OPENVPN_PASSWORD=<secret>
      - TZ=America/Los_Angeles
    restart: always

  deluge:
    image: linuxserver/deluge
    container_name: deluge
    restart: always
    network_mode: "service:gluetun"
    environment:
      - PUID=0
      - PGID=0
      - TZ=America/Los_Angeles
    volumes:
      - /share/Container/config/deluge/config:/config
      - /share/Container/config/deluge/incomplete:/incomplete
      - /share/Download:/downloads
      - /share/Public/Comics/Downloaded:/comics
    mem_limit: 3g
    memswap_limit: 3g
    cpus: '1.0'
    oom_kill_disable: true

  sabnzbd:
    image: ghcr.io/linuxserver/sabnzbd
    container_name: sabnzbd
    environment:
      - PUID=0
      - PGID=0
      - TZ=America/Los_Angeles
    volumes:
      - /share/Container/config/sabnzbd:/config
      - /share/Download:/downloads
    network_mode: "service:gluetun"
    restart: unless-stopped

  jackett:
    image: ghcr.io/linuxserver/jackett
    container_name: jackett
    environment:
      - PUID=0
      - PGID=0
      - TZ=America/Los_Angeles
      - AUTO_UPDATE=true
    volumes:
      - /share/Container/config/jackett:/config
      - /share/Download/torrents:/downloads
    network_mode: "service:gluetun"
    depends_on:
      - gluetun
      - deluge
    restart: unless-stopped

  mylar3:
    image: linuxserver/mylar3
    container_name: mylarr
    environment:
      - PUID=0
      - PGID=0
    volumes:
      - /share/Container/config/mylarr:/config
      - /share/Public/Comics:/comics
      - /share/Download:/downloads
    depends_on:
      - deluge
      - sabnzbd
      - jackett
    restart: unless-stopped

  lidarr:
    image: linuxserver/lidarr
    container_name: lidarr
    environment:
      - PUID=0
      - PGID=0
      - TZ=America/Los_Angeles
    volumes:
      - /share/Container/config/lidarr:/config
      - /share/Music:/music
      - /share/Download:/downloads
    depends_on:
      - deluge
      - sabnzbd
      - jackett
    restart: unless-stopped

  radarr:
    image: linuxserver/radarr
    container_name: radarr
    volumes:
      - /share/Container/config/radarr:/config
      - /share/Videos/Movies:/movies
      - /share/Download:/downloads
    depends_on:
      - deluge
      - sabnzbd
      - jackett
    restart: unless-stopped
    environment:
      - PUID=0
      - PGID=0

  sonarr:
    image: linuxserver/sonarr
    container_name: sonarr
    volumes:
      - /share/Container/config/sonarr:/config
      - /share/Container/config/docker-mp4-automator/tv:/tv
      - /share/Videos/Shorts:/shorts
      - /share/Videos/Anime:/anime
      - /share/Download:/downloads
    depends_on:
      - deluge
      - sabnzbd
      - jackett
    restart: unless-stopped
    environment:
      - PUID=0
      - PGID=0

Obviously I can fix the issues with not being able to access Sonarr/Radarr by going back to my old way of doing things (having them separate from the Gluetun network)... but that doesn't solve the The operation has timed out: 'http://192.168.86.222:8112/json' issue. Any ideas?

[Jay2645]

...And it mysteriously disappeared? After putting everything on the same network and changing Sonarr/Radarr/etc. to 127.0.0.1, everything magically started to work.

I always hate seeing these answers elsewhere, but for me just "turning it off and on again" with the above docker-compose seemed to work fine.

[qdm12]

I'm not sure a container connected to gluetun can reach things through your LAN (192.168.86.222?), but they can reach each others through 127.0.0.1 as you have found.

Is that what you were trying to do?

[Jay2645]

Sort of... Chrome is able to access stuff over the LAN, but the containers couldn't. I can access Deluge, Sonarr, Radarr, etc. through Chrome by typing in 192.168.86.222: and it seems to resolve fine, from any computer on my LAN. However, the other containers in my docker-compose couldn't do what my Chrome web browser could, and that confused me.

My issue was that I didn't set the network_mode on the other containers. Once I moved all the containers in that same docker-compose file to share the same network through network_mode: "service:gluetun", the problem (eventually) resolved itself.

The reason why I made this post was because when I first tried that, it seemed like things weren't resolving. However, that problem was between the chair and the keyboard: I didn't wait long enough for Sonarr/Radarr/etc. to bring up their web servers (since they had to wait for Gluetun first). So since the webserver wasn't quite up yet... of course I couldn't connect.

After actually waiting for the Radarr web server to actually come online, I could connect to its web UI. Then I just changed them to access Deluge through localhost and everything was fine. Just a little embarrassing...

[qdm12]

Haha no problem! I'm glad you resolved it. I also like your expression that problem was between the chair and the keyboard 😄

Finally, it might because there is some firewall and routing gymnastics so maybe LAN devices can access it through the host IP address (their only choice), whereas processes local to gluetun can't (due to firewall and routing). But it's so intricate, it's also a bit vague for myself 😆

What I know is we had a long standing (=years) problem to reach a port published on gluetun from outside the LAN of your machines, so there is now quite a bit of gymnastics to allow that without user input!

[ab3lson]

I am trying to do the same thing as you, but Radarr/ Sonarr can’t see jackett. How did you get around this issue? When I try to add the port for jackett as an indexer on either of them, it says that it can’t connect. When I change the IP to 127.0.0.1 and put jackett’s port on there, it instantly fails.

[qdm12]

Maybe try with localhost instead of 127.0.0.1? are all (Radarr sonarr and jacket) using gluetun as their network stack?