Cat_Seeder

Humm. I'm not familiar with Proton VPN, but I would check if they support Port Forwarding. Without it you will have a half-baked experience at best. No incoming connections means passive mode. You will get in trouble in private trackers. In public trackers you may not find many (or even any peers)... If you want to set up a VPN always check if they do allow port forwarding and if the port that you have opened is reachable (https://www.yougetsignal.com/tools/open-ports/). Other than that, while it is not related to your issue, you may not be able to access the webui remotely (see Q2 at

Sorry, took a while trying to fix it by myself (and I've "succeeded"). Initially I was having the same errors as before: 2019/03/16 04:36:26 [error] 904#904: *3 connect() failed (113: Host is unreachable) while connecting to upstream, client: 192.168.X.Y, server: mydomain.local, request: "GET / HTTP/1.1", upstream: "http://192.168.X.Y:3000/", host: "mydomain.local" Turns out that Docker wouldn't me to access my host IP (be it public or internal) without --net=host. That's of course, an undesirable workaround. A better solution is to create a user-defined bridge network so that containers can talk directly. After doing that I've enabled IPv6 and modified NGINX configuration: listen 8080; listen [::]:8080; And finally it worked as expected: $ curl -6 -g -v -H "Host: mydomain.local" http://[::1]:8080 * Rebuilt URL to: http://[::1]:8080/ * Trying ::1... * TCP_NODELAY set * Connected to ::1 (::1) port 8080 (#0) > GET / HTTP/1.1 > Host: mydomain.local > User-Agent: curl/7.60.0 > Accept: */* > < HTTP/1.1 200 OK [16/Mar/2019:05:14:09 +0000] - 200 200 - GET http mydomain.local "/" [Client 192.168.X.Y] [Length 543] [Gzip -] [Sent-to 192.168.X.Y] "curl/7.60.0" "-" [16/Mar/2019:05:18:40 +0000] - 200 200 - GET http mydomain.local "/" [Client ::1] [Length 543] [Gzip -] [Sent-to 192.168.7.2] "curl/7.60.0" "-" However, I have to say that while I love the Nice UI and have nothing but praise for the Developers, the container is not really what I was expecting. It is not currently able to generate configuration on the fly when I run new containers (that's probably the most important feature of jwilder/nginx-proxy); plus, I quickly outgrown the UI and had to intervene manually in order to make the container work with IPv6, make it play well with Syslog, etc. You will need to set a Proxy Host configuration for the http port (9981) and a stream for the other port (9982). In the Stream configuration UI you can select a different port than 8080 (or whatever you http port is). Don't forget to publish that second port (e.g., -P 9982:9982) and add a rule to allow incoming traffic to that port in your firewall.

I would probably drop Kinematic all together and go native (e.g., Docker Desktop). I'm not familiar with Kitematic, but it seems to be binding ports to localhost only (e.g. -p 127.0.0.1:32862:9080 instead of -p 9080:9080). The CLI is not that hard to learn; plus not having to deal with Docker Toolbox / VirtualBox will make your life easier.

Hi Djoss, no luck with my local (192.168.x.y) or public IPs :(. Any other ideas? My setup is: * Linux Host * Your image running on Docker * Another image running on Docker, exposing port 3000 to the router. Accessing my local IP directly works and nginx-proxy image works as expected. Any other ideas?

Just sharing one of the links that I've sent you in private yesterday in case anyone else hits the same issue. Please ignore the Haproxy specific tweaks: https://medium.com/@pawilon/tuning-your-linux-kernel-and-haproxy-instance-for-high-loads-1a2105ea553e Number of open files, max TCP connections and "reservation" times can all affect the end result when dealing with a large amount of torrents. I'm on Linux (not Unraid) and had to fine tune the host to get it all working with 1k+ torrents.

Flood listens in port 3000. Rutorrent listens in port 9080 and 9443 (Https). If you want both you can set ENABLE_FLOOD to BOTH. Be warned that, while it looks great, flood uses a lot of memory and is not as feature complete as rutorrent. With 1k torrents Flood's Node.js process is using quite a bit of memory, plus the UI lags so much that it's barely usable; Rutorrent is still doing "reasonably" fine. As for rutorrent not starting, try to start from scratch. Delete the container, pull the latest image and start with a fresh volume / host folder bound to the container's /config folder.

I think so. Have a look at the documentation bellow: enable_retry will turn off encryption in the second case. So basically the difference is that 1) Tries plain text first and then retry with encryption. If client can do both it will prefer plaintext 2) Tries encryption first and then retry plain text. If client can do both it will prefer encryption. Both strategies, in theory, will allow the user to connect with any kind of peer. Effects on speed are somewhat hard to predict. All things being equal, plaintext is probably faster. However, if the ISP is traffic shaping, encryption will probably boost the speeds. Maybe go for 1 when VPN is enabled and 2 otherwise?

@binhex, I'm sorry to keep bothering you. Just want to check something. In rtorrent.rc we have: protocol.encryption.set = allow_incoming,enable_retry,prefer_plaintext As far as I understand rTorrent will work in plain text mode by default right? Is there a reason not to change it to something like: protocol.encryption.set = allow_incoming,try_outgoing,enable_retry So that it tries to use RC4 encryption when possible? As far as I understand this is safer and it's a good neighbour police (helps people that do not use a VPN).

I haven't tried it myself but if rTorrent + flood is all you need maybe the following image may fit the bill: https://hub.docker.com/r/wonderfall/rtorrent-flood You may, of course, use binhex's image with the correct flags to disable vpn, privoxy and ruTorent + autodl-rssi, however, given that you do not need 80% of its features, if might feel like driving your kids to school with a lorry :).

Hi guys, Thanks for the great container. Amazing work. I'm currently trying to migrate from the also excellent (but CLI oriented) Jason Wilder nginx-proxy container. So far I have a couple of problems: IPv6 support. Looks like the proxy is failing to forward to the desired destination when I reach it over IPv6. I'm looking for something around the lines of nginx-proxy's: ENABLE_IPV6=true Is IPv6 supported? I've tried manually adding listen [::]:8080; to the server block in /config/nginx/proxy_host/3.conf, however, the proxy is currently returning 502 Bad Gateway: $curl -g -6 -v -H "Host: mydomain.local" http://[::1]:8080 * Rebuilt URL to: http://[::1]:8080/ * Trying ::1... * TCP_NODELAY set * Connected to ::1 (::1) port 8080 (#0) > GET / HTTP/1.1 > Host: mydomain.local > User-Agent: curl/7.60.0 > Accept: */* > < HTTP/1.1 502 Bad Gateway < Server: nginx < Date: Sat, 09 Mar 2019 16:06:32 GMT < Content-Type: text/html < Content-Length: 166 < Connection: keep-alive < <html> <head><title>502 Bad Gateway</title></head> <body bgcolor="white"> <center><h1>502 Bad Gateway</h1></center> <hr><center>nginx</center> </body> </html> * Connection #0 to host ::1 left intact Error logs: [error] 872#872: *2 connect() failed (111: Connection refused) while connecting to upstream, client: 172.17.0.1, server: mydomain.local, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:3000/", host: "mydomain.local" I can reach port 3000 directly from my host. nginx-proxy container is also able to proxy it with no issues. Consolidated logs. Another problem is consolidating and formatting the logs. I would like to have a consolidated view of the logs (i.e., everything at /config/nginx-proxy-manager/logs/) so that I can send it to another tool. I would also like to be able to customise its format. At the moment I'm using multitail to consolidate the logs and manually editing nginx configuration files to customise formatting. However, it would be great if there was a more permanent solution to the problem. All of the best

I understand. This may not be a very popular opinion given that lots of people are running your image in very limited devices such as an entry level NAS. However, maybe it would be worth it to break down services in separate containers, potentially binding everything together with a "do it all" docker compose file? E.g., one image with openVPN + port forwarding stuff, one image with rtorrent-ps exposing just port 5000, one image with rutorrent, one image with flood, one with privoxy, etc. That way you will be able to add features to individual images without worrying too much about overly bloated containers. Looks very promising. The GUI is awesome. Straight out of the box beats my solution. I just need to check if it is working well with IPv6 Thanks for the great hint. Not sure why I haven't found the container above while looking for it :).

TYVM for considering it. Stats in my machine: filemanager + fileuploader folders: 344.9 KiB zip package: 549.6 KiB rar package (AUR): 862.6 KiB rutorrent: each one of the nginx containers are now averaging around 1640 K. Before installing both plugins containers where using around 1550 K - 1580 K each. Overall it is a very lightweight set of plugins, however, I do understand that it is one more thing to manage in an image that is already doing a lot :). --- Different topic: I'm also making a lot of progress with nginx reverse proxy. My containers have been running smoothly for around 10 days. I've created a docker-compose projects that servers rtorrentvpn + nginx-proxy. It is currently able to expose rutorrent and optionally flood to the internet with their own custom domains (e.g., rutorrent.mydomain.xyz and flood.mydomain.xyz) over https, with A+ SSL scores. It works over IPv4 and IPv6 (for those of us behind CGNAT). I don't think that my solution is complex enough to deserve it's own git repo for now. Is this something worth sharing in the forums? Cheers,

Great stuff @binhex. I did manage to make it work adjusting some of the OP instructions. I left a few comments in the GitHub issue. File Manager is probably a very good addition to your image. It's certainly very useful when you are sharing your "seedbox" with non-technical users or just need a quick way to decompress a set of rar files, etc remotely (It comes out of the box in most managed seedboxes). I've noticed that, so far, there are no PRs merged to your repo, so I didn't take the time to open a PR. However, if you do decide to add support for file manager, I can send you a patch (afaic my patch is public domain). Otherwise, I think that my instructions should be good enough to add support from scratch with no hassle. If you do decide to add support (or at least install zip and rar packages) it would be great. That way I can avoid building images locally.

No noticeable regressions after the upgrade. Memory consumption is holding well. rtorrent process using around 55 MB memory with a couple of torrents and about the same as before with ~1000 torrents. I was expecting much more of a hit given the extra features. Fantastically done. I still can't manage to install FileManager with the ruTorrent v3.8 + rtorrent 0.9.6/0.13.6 combo. Don't know what I'm doing wrong :(.

I've been using rtorrent-ps + tmux in a VPS for a while. It works great. Version downgrade is fine by me. Just need to double check if that specific version is not blacklisted in any major private trackers. Unrelated to above: Did anyone manage to get FileManager, FileShare and / or Unpack to work? If so, can you please share the version and installation instructions that you have used? I've tried the custom plugin folders but all plugins end up in "unloaded" state.

I gave my server a domain name and it is working fine with Remote Torrent Adder. I have a real domain with a DNS entry pointing to my box so that I can access it from the internet. However, inside a LAN you can get away with setting a Domain Name in your DHCP server (e.g., your Router) and a hostname for your NAS. I don't own a Synology router, however, most Linux based distros will update /etc/hostname with whatever you have selected as the server name. I wouldn't bother with SSL if you are only using it in your LAN (Port 9080 / SSL off should be fine). If you are outside of your LAN you will need to either generate a valid SSL certificate (e.g., with Let's Encrypt) or import the container self signed certificate (https://github.com/bogenpirat/remote-torrent-adder/wiki/Import-self-signed-certificates)

Humm... That's interesting. At the moment I can access the rutorrent exposed port through my host IP address (i.e., http://[20xx:yyyy:yyyy:yyyy:yyyy:yyyy:yyyy:yyyy]:9080 works when the request comes from inside my lan). Is the IPv6 request getting translated to IPv4 somehow when I access it inside my LAN?

Hi guys, I'm sorry to bother but I'm still struggling with this. Although I understand that external connectivity is not a functionality of the container per see, any help would be very welcome. I really think that this is a problem related with IPv6 and the container iptable and network settings. If I tunnel traffic through IPv4 (i.e., ngrok) everything works well. However, I'm stuck behind cgnat and would very much like to have a direct connection to my host. The symptoms that I'm witnessing are very similar to the ones reported by people trying to set up a reverse proxy (with nginx, traefick, etc). Has anyone managed to get their reserve proxy working? If so, could you please share a copy of your configuration? Kind regards,

Hi guys, Just wondering if anyone managed to expose rTorrent's interface to the web over IPv6. So far I have: Deleted the default admin user / created a non-standard one Created an SSL certificate and replaced the original certs in /config/nginx/certs Exposed ports 9080 and 9443 in my router's firewall Add an AAAA record on my domain pointing to my IPv6 address From inside my LAN everything works fine. I can access rTorrent using my custom domain over http and https with no problem. From outside my LAN I can only access rTorrent through http, and the UI only loads partially (it gets stuck trying to request getplugins.php). And I missing something? It definitively looks like I need to open a few more ports. Plus, I may be missing something regarding the container's iptable rules. I.e., what should LAN_NETWORK be?