SabNZBd Reserse Proxy V3.0.1 Docker - rss feeds

1. Caddy version (caddy version):

Caddy 0.11.2 (+f249158) (unofficial)

2. How I run Caddy:

Docker Compose
image: jessestuart/caddy:latest

a. System environment:

b. Command:

n/a

c. Service/unit/compose file:

caddy:
    container_name: caddy
    image: jessestuart/caddy:latest
    restart: always
    environment:
      - ACME_AGREE=true
      - CLOUDFLARE_EMAIL=<removed>
      - CLOUDFLARE_API_KEY=<removed>
    networks:
      - caddy-proxy
    ports:
      - 443:443
      - 80:80
      - 8480:8480
      - 8443:8443
    secrets:
      - cloudflare_api
      - cloudflare_email
    dns:
      - 192.168.10.1
      #- 8.8.8.8
    volumes:
      - ./caddy/certs:/root/.caddy
      - ./caddy/srv:/srv
      - ./caddy/Caddyfile:/etc/Caddyfile

d. My complete Caddyfile or JSON config:

(tls) {
    tls letsencrypt@domain.com {
        dns cloudflare
        wildcard
    }
}
https://sabnzbd.internal.domain.com {
    import tls
    log / stdout "Sabnzbd        : {common}"
    proxy / http://drogo.local:8086/ {
        transparent
        #websocket
        insecure_skip_verify
    }
}

DO NOT REDACT anything except credentials

3. The problem I’m having:

Sabnzbd has been workign fine, and is fine to access via the url https://sabznbd.internal.domain.com for my internal network (this is not exposed).

But with the update to sabnzbd linuxserio docker image) and v3.0.1 most of the site navigation is fine, until you go to the rss feed and hit the read feed button.
image
This is supposed to trigger a read of the rss feed and navigate to it, But wiht the update in version it does nothing anymore, and looking at the sab log it doesn’t trigger an action.

If I ignore the reverse proxy and go to the http://drogo.local:8086 directly, all works as it should.

4. Error messages and/or full log output:

No error, but the caddy log has the following when you hit that rss feed button:

Sabnzbd        : 192.168.10.141 - - [29/Aug/2020:03:10:47 +0000] "POST /config/rss/test_rss_feed HTTP/2.0" 303 120

5. What I already tried:

6. Links to relevant resources:

You’re using an extremely old version of Caddy. Please upgrade to Caddy v2.

You can find the Docker image for Caddy v2 here: Docker Hub

Our upgrade guide is here:

Also note the steps to build Caddy with plugins on the Docker Hub readme. Read this below article to learn how to use DNS plugins in Caddy v2:

I never found answers to upgrading my caddy file

Nor could work out if cloudflare was supported so never looked past an initial upgrade.

Yes cloudflare is supported. I even gave you the instructions in that thread you linked for building with cloudflare support.

Like @matt said in that thread, just use a * in your site label if you must have a wildcard cert.

I don’t understand what else is unclear.

I’ll have to try again, I don’t think I got any of it working back then.

You can see at the bottom of that thread I’d asked about referencing Tls (the import statement) in the new format caddy file.

Your config for v2 could look like this:

*.internal.domain.com {
	tls {
		dns cloudflare <your_api_token>
	}
	log

	@sabnzbd host sabnzbd.internal.domain.com
	reverse_proxy @sabnzbd drogo.local:8086

	@unifi host unifi.internal.domain.com
	reverse_proxy @unifi 192.168.10.41:8444
}

Ahh that got me a little further…and got me looking at the image I was using/building for cloudflare.

I saw I had my api key not working, and saw that I need a dns specific one and not the global. I thinkI’ve got something wrong with how I’m passing it to docker-compose, but I’ve got around that so far by hard coding.

Looking at the same one, I’m just working out the https to http reverse proxying to get that working.

I can see the request

caddy        | {"level":"info","ts":1598757325.9385955,"logger":"http.log.access","msg":"handled request","request":{"method":"GET","uri":"/","proto":"HTTP/2.0","remote_addr":"192.168.10.162:55410","host":"sabnzbd.internal.domain.com","headers":{"Sec-Fetch-User":["?1"],"Sec-Fetch-Dest":["document"],"Accept-Encoding":["gzip, deflate, br"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9"],"Sec-Fetch-Site":["none"],"Upgrade-Insecure-Requests":["1"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.135 Safari/537.36"],"Sec-Fetch-Mode":["navigate"],"Accept-Language":["en-NZ,en;q=0.9,en-AU;q=0.8"],"Cookie":["_ga=GA1.2.1395989566.1591129862"],"Cache-Control":["max-age=0"],"Dnt":["1"]},"tls":{"resumed":false,"version":772,"ciphersuite":4865,"proto":"h2","proto_mutual":true,"server_name":"sabnzbd.internal.domain.com"}},"common_log":"192.168.10.162 - - [30/Aug/2020:03:15:25 +0000] \"GET / HTTP/2.0\" 0 0","duration":0.000009901,"size":0,"status":0,"resp_headers":{"Server":["Caddy"]}}

So is the GET / HTTP/2.0" 0 0 the status code of the response? Like a 200, 404 etc? As I’m not seeing what I expect anywhere in that log.

Got it now, had the reverse_proxy for sabnzbd crossed up with the unifi one, so that’s why is was getting no response.

So not I’ve got my original problem back on caddy 2.1.1/

caddy        | {"level":"info","ts":1598758201.325422,"logger":"http.log.access","msg":"handled request","request":{"method":"GET","uri":"/config/rss/","proto":"HTTP/2.0","remote_addr":"192.168.10.162:55503","host":"sabnzbd.internal.domain.com","headers":{"Dnt":["1"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.135 Safari/537.36"],"Sec-Fetch-Site":["cross-site"],"Sec-Fetch-Mode":["navigate"],"Sec-Fetch-User":["?1"],"Sec-Fetch-Dest":["document"],"Cache-Control":["max-age=0"],"Upgrade-Insecure-Requests":["1"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9"],"Accept-Encoding":["gzip, deflate, br"],"Accept-Language":["en-NZ,en;q=0.9,en-AU;q=0.8"],"Cookie":["_ga=GA1.2.1395989566.1591129862"]},"tls":{"resumed":false,"version":772,"ciphersuite":4865,"proto":"h2","proto_mutual":true,"server_name":"sabnzbd.internal.domain.com"}},"common_log":"192.168.10.162 - - [30/Aug/2020:03:30:01 +0000] \"GET /config/rss/ HTTP/2.0\" 200 6460","duration":0.008643775,"size":6460,"status":200,"resp_headers":{"Server":["Caddy","CherryPy/unknown"],"Content-Length":["6460"],"Content-Type":["text/html;charset=utf-8"],"Date":["Sun, 30 Aug 2020 03:30:01 GMT"],"X-Frame-Options":["SameOrigin"],"Vary":["Accept-Encoding"],"Content-Encoding":["gzip"]}}

Is the log entry for hitting the Read Feed button. It just sits there after hitting the button. It used to trigger a read then navtigate tothe feed page:

caddy        | {"level":"info","ts":1598758209.1884356,"logger":"http.log.access","msg":"handled request","request":{"method":"GET","uri":"/config/rss/?feed=Books-Nzbgeek","proto":"HTTP/2.0","remote_addr":"192.168.10.162:55503","host":"sabnzbd.internal.domain.com","headers":{"Dnt":["1"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9"],"Sec-Fetch-Dest":["document"],"Accept-Language":["en-NZ,en;q=0.9,en-AU;q=0.8"],"Accept-Encoding":["gzip, deflate, br"],"Cookie":["_ga=GA1.2.1395989566.1591129862"],"Upgrade-Insecure-Requests":["1"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.135 Safari/537.36"],"Sec-Fetch-Site":["same-origin"],"Sec-Fetch-Mode":["navigate"],"Sec-Fetch-User":["?1"],"Referer":["https://sabnzbd.internal.domain.com/config/rss/"]},"tls":{"resumed":false,"version":772,"ciphersuite":4865,"proto":"h2","proto_mutual":true,"server_name":"sabnzbd.internal.domain.com"}},"common_log":"192.168.10.162 - - [30/Aug/2020:03:30:09 +0000] \"GET /config/rss/?feed=Books-Nzbgeek HTTP/2.0\" 200 17283","duration":1.473514768,"size":17283,"status":200,"resp_headers":{"Date":["Sun, 30 Aug 2020 03:30:07 GMT"],"X-Frame-Options":["SameOrigin"],"Vary":["Accept-Encoding"],"Content-Encoding":["gzip"],"Server":["Caddy","CherryPy/unknown"],"Content-Length":["17283"],"Content-Type":["text/html;charset=utf-8"]}}

Did you check the browser console? Are there any javascript errors in there? The Caddy logs look fine.

I don’t know enough about how sabnzbd works internally to say. (I used to use sab a few years ago but I’ve since switched to nzbget, I like it better).

I’ve updated the sab version, and fiddled (that’s a technical term) in the console for chrome to allow insecure content and popups etc.

I can see:

Mixed Content: The page at 'https://sabnzbd.internal.domain.com/config/rss/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://sabnzbd.internal.andc.nz/config/rss/?feed=Apps'. This content should also be served over HTTPS.
(index):1 Access to XMLHttpRequest at 'http://sabnzbd.internal.domain.com/config/rss/?feed=Apps' (redirected from 'https://sabnzbd.internal.domain.com/config/rss/test_rss_feed') from origin 'https://sabnzbd.internal.domain.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: Redirect is not allowed for a preflight request.

This is back on the old version of caddy. If this something caddy can “fix” for me. I can go down the path of https via caddy to https version of sabnzbd, but tend to use the http version currently when doing any reverse proxying.

I would call that a sabnzbd bug then. They’re telling the browser to load something over HTTP when you’re making requests over HTTPS. There might be some config flag you can set to make it work better, but you should report this to the sabnzbd team so they can fix it.

Yeah I’ve mentioned it over there as well. I’ll progress working on a newer caddy 2 config (both v1 and v2 caddy had the same issue).

Need to work out a websocket entry for a unifi entry then I’ll be happy to start migrating over.

Thanks for your help.

This topic was automatically closed after 30 days. New replies are no longer allowed.