Source
r/sonarr•
bterps

*arr clients cannot connect to Jackett using reverse proxy

unsolved

Looking for a little help, I'm unable to connect to any of my indexers in Jackett if the URL takes the form of http(s)://jackett.tld.com, I've also tried http(s)://jackett.tld.com:9117. But if I use the local ip of the machine http://192.168.XX.XX:9117 then it can connect.

I use Caddy as a reverse proxy and I can access the GUI for Jackett at https://jackett.tld.com. Addtionally, if I try to check via curl it seems to work:

curl https://jackett.tld.com/api/v2.0/indexers/xspeeds/results/torznab/
<?xml version="1.0" encoding="UTF-8"?>
<error code="100" description="Invalid API Key" />%

So i'm at a bit of a loss, any ideas?

Posted Jan 28, 2023, 11:52 AM UTC

611
PearsonFlyersupport•

This is a reverse proxy issue, BUT why are you exiting your network to come back in? Do you also leave through the front door, walk around your house to the back door when you want something out of the fridge?

4
MasterChiefmas•

BUT why are you exiting your network to come back in?

He's not necessarily exiting the network if hairpinning is turned on at his router. It'll identify the request and just put it back on the local, it won't send it out.

2
astalush•

Exactly the thing I wanted to say, if all is local, stay local.

1
bterpsOP•

Not leaving and coming back in, local DNS record to point subdomains to the server

If the reverse proxy is the issue, curl & the GUI should also fail, no?

1
AutoModeratorMOD•

Hi u/bterps -

There are many resources available to help you troubleshoot and help the community help you. Please review this comment and you can likely have your problem solved without needing to wait for a human.

Most troubleshooting questions require debug or trace logs. In all instances where you are providing logs please ensure you followed the Gathering Logs wiki article to ensure your logs are what are needed for troubleshooting.

Logs should be provided via the methods prescribed in the wiki article. Note that Info logs are rarely helpful for troubleshooting.

Dozens of common questions & issues and their answers can be found on our FAQ.

Please review our troubleshooting guides that lead you through how to troubleshoot and note various common problems.

If you're still stuck you'll have useful debug or trace logs and screenshots to share with the humans who will arrive soon. Those humans will likely ask you for the exact same thing this comment is asking..

Once your question/problem is solved, please comment anywhere in the thread saying '!solved' to change the flair to solved.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

1
asdfgugus•

Seems to me that the issue is related to your reverse proxy. Did you check the logs?

1
bterpsOP•

If the reverse proxy was the issue, i shouldn't be able to access the GUI either, no?

I looked at logs in *arr, not at the reverse proxy. Logs in Caddy are kinda annoying so haven't set it up

1
asdfgugus•

From where did you send the curl command? If you use containers, you should try to reach it from inside. Maybe you did not specify your internal DNS server?

You can get shell access in docker like this:
sudo docker exec -ti <container-name> /bin/bash

Otherwise I have no further Idea without any logs. I am pretty sure you would find your issue in the logs.

1
solidfreshdope•

If it’s on the same host just call it by “jackett” or whatever the container name is.

1
MasterChiefmas•

I've also tried http(s)://jackett.tld.com:9117. But if I use the local ip of the machine http://192.168.XX.XX:9117 then it can connect.

Is this from within your local network? Where are you running the curl from, another machine on the local network? What's the DNS name resolve to, a public IP, or an internal one? I'm assuming public since you have https available(most people don't bother with certs for only internally accessible things).

The most typical reason this kind of thing happens(works from IP but not DNS name) is that your DNS name is pointing to the public IP of the router. Lots of routers, when they get a request to the WAN IP from the LAN side, instead of sending the request out and back in(which would work) instead accept the request as one intended for the router itself. This is normally resolved by enabling NAT hairpinning, so that instead of doing that, the router processes the packet as though it were sent to the public IP from outside, thus processing fw and forwarding rules normally, and forwarding the traffic properly to the designated host in the LAN.

However, your description of what you've tested, this may not be the case, it depends on where the machine is when you run the curl.

1
bterpsOP•

No hairpin nat, but I have local DNS on my router to point all subdomains to my server. I'm essentially only using the subdomains to make accessing the service UI's easy.

Running curl from another machine on the LAN

1