Anyone using Caddy on Docker on a Synology NAS (as Reverse Proxy only)?

Help
36

I did have a second DDNS setup that I was wanting to move to. I used that and a different email address.

I redid everything and made a new container, including the 3 aliases. It will not create the container. It bothers me as I dont understand a reason.

I remove those 3 aliases. Then it creates the container and starts up perfectly. Everything is working from my cellphone not on my wifi. Sonarr, RAdarr, and Synology are perfect. I am indeed using my NAS IP address in my caddy file since i cant get it to take the aliases.

WHat else can i try in regards to getting that to work with aliases? very weird.

nzbget isn’t working. I do have nzbget requiring its stock userID and pw. First I get prompted for the proxy pw via pop-up. Then I get another pop-up that I presume is the nzbget web password. Does that not play nice together and I should remove the nzbget web server app password?

37

NZBGet auth is basic too, I think. Turn it off. Basic auth uses the Authorization header, which obviously can’t hold both Caddy’s required credential and NZBGet’s as well (unless they’re identical).

1 Like
38

Yep that was it. Looking in the logs, it was indeed passing the basic auth creds to nzbget! I guess I dont need it any more anyway!

39

So far so good still! So happy! Ill whip up a guide for the community and see if any other tweaks needed.

Are you familiar with nzb360? Technically i don’t need it, but curious if you know how to get it working with caddy.

It allows for local and remote setup. basically using a comma.
My local setup works fine, but I cannot get remote to work.
The key fields are:
IP/Host Address (notes to input HTTP auth as user:pass@host): IP_OF_NAS,myuser:mypass@CustomDDNSName.DDNSProvider.com

Server Port (If you are using a sub dir, enter it after the port): 8989/sonarr,80/sonarr

I assume its probably an issue with caddy starting at 80 and then wanting to go to 443?

I found one older thread: nzb360

40

I also took a stab at converting to the full CNAME setup and merging into one Caddyfile without common.conf.

https://zerobin.net/?fb716416c8de9ebd#P2Ymysw6yAXrqPtn+QPJR+8zT3rcJkIEyKxmgRqbdHA=

Thoughts? definitely less pleasing to look at! What are your thoughts on condensing? Maybe go back to common.conf?

I was unsure how to handle the redirs for sure, but took a guess

41

Tried it a while back. It never played nice for me, not through Caddy remotely. But I’ve found the webapps render just fine on mobile regardless.

A pretty good stab I’d say, but you’re right about it looking a little less pleasing without the common.conf…

To be honest, here’s my entire Caddyfile:

sub.example.com {
	tls sub@example.com
	errors stdout
	log stdout
	gzip
	
	header / {
		Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
		X-XSS-Protection "1; mode=block"
		X-Content-Type-Options "nosniff"
		X-Frame-Options "DENY"
	}

	basicauth [user] [pass] {
		/radarr
		/hydra
		/nzbget
		/sonarr
	}

	proxy /radarr 192.168.1.123:7878
	proxy /hydra 192.168.1.123:5075
	proxy /nzbget 192.168.1.123:6789
	proxy /sonarr 192.168.1.123:8989
	proxy /ombi 192.168.1.123:3579
	proxy / 192.168.1.123:19999
}

sub.example.com/couchpotato {
	redir /radarr/
}
1 Like
42

Awwww yisssssss much nicer and clean.

Will this will work fully using the CNAME approach and I should then remove the URL base pieces from each app where applicable?

I also wanted to clarify how to handle the synology 5000 port route.

I also wanted to clarify how to handle the circumstance when just the root / is used. In my case I want / to go to sonarr.

Do I need a basicauth for when just / is accessed and routes to sonarr? Or maybe not because it then routes to sonarr which needs the auth?

updated Caddyfile: (how do you get the tabs in the quotes to work???)

YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
  tls YOUR_EMAIL@YOUR_EMAIL_PROVIDER.X
  errors stdout
  log stdout
  gzip

header / {
Strict-Transport-Security “max-age=31536000; includeSubDomains; preload”
X-XSS-Protection “1; mode=block”
X-Content-Type-Options “nosniff”
X-Frame-Options “DENY”
}

basicauth YOUR_USERID YOUR_PASSWORD {
/nzbget
/sonarr
/radarr
/synology
}

proxy /nzbget YOUR_NAS_LOCALIP:6789
proxy /sonarr YOUR_NAS_LOCALIP:8989
proxy /radarr YOUR_NAS_LOCALIP:7878
proxy /synology YOUR_NAS_LOCALIP:5000
proxy / YOUR_NAS_LOCALIP:8989 # Root will take to Sonarr
}

nzbget.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
redir /nzbget/
}

sonarr.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
redir /sonarr/
}

radarr.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
redir /radarr/
}

synology.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
redir /synology/
}

43

Use three backticks to make code blocks :wink: (Markdown)

2 Likes
44

Done! I had to google backticks! :grin:

45

All apps proxied into a subfolder must have their URL base set.

In your updated Caddyfile, it looks like you’ve proxied both / and /sonarr to Sonarr. I would instead redir / /sonarr. To answer your next question as well, a basicauth on /sonarr will then handle that when the client arrives.

Those redirs look good. One note - does Synology have a URL base option? I thought you were going to proxy synology.example.com to your NAS, not example.com/synology, but I maybe wrong.

1 Like
46

Oh yes, the synology does not have a base URL option… i just need to get to YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X:5000

so i need to add a redir higher up and then a full site below? do I also need to add another basicauth for the synology piece?

do we not need the transparent preset anywhere?

here’s the revised slim version:

YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
  tls YOUR_EMAIL@YOUR_EMAIL_PROVIDER.X
  errors stdout
  log stdout
  gzip

header / {
Strict-Transport-Security “max-age=31536000; includeSubDomains; preload”
X-XSS-Protection “1; mode=block”
X-Content-Type-Options “nosniff”
X-Frame-Options “DENY”
}

basicauth YOUR_USERID YOUR_PASSWORD {
/nzbget
/sonarr
/radarr
}

proxy /nzbget YOUR_NAS_LOCALIP:6789
proxy /sonarr YOUR_NAS_LOCALIP:8989
proxy /radarr YOUR_NAS_LOCALIP:7878
proxy /synology YOUR_NAS_LOCALIP:5000
redir / /sonarr # Root will take to Sonarr
redir /synology synology.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X
}

nzbget.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
redir /nzbget/
}

sonarr.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
redir /sonarr/
}

radarr.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
redir /radarr/
}

synology.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
proxy / YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X:5000
}

47

Rip out the proxy /synology, it’s useless with redir /synology (redir beats proxy).

Change redir /synology synology.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X to redir /synology https://synology.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X , will avoid a double redirect (from Caddy HTTP->S upgrade).

Under the label block for synology.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X, yes, add a blanket basicauth / here. Also change the upstream to YOUR_NAS_LOCALIP, currently it proxies to itself but on port 5000 (I hope this is not open externally).

Not terribly, no. Sonarr, Radarr, and NZBGet don’t particularly care who the real client is and function just fine without knowing.

Looking good otherwise!

Edit: Also minor heads up - in my header block from my “slim” Caddyfile I didn’t bother with -Server. I don’t know if you caught that removal but just in case you particularly want to have that, you should re-add it.

1 Like
48

Thank you so much!

I do not have port forwarding to 5000 on my router, so it should not be exposed externally, should I test this somehow?

One final check please before i create this guide!

YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
  tls YOUR_EMAIL@YOUR_EMAIL_PROVIDER.X
  errors stdout
  log stdout
  gzip

header / {
Strict-Transport-Security “max-age=31536000; includeSubDomains; preload”
X-XSS-Protection “1; mode=block”
X-Content-Type-Options “nosniff”
X-Frame-Options “DENY”
}

basicauth YOUR_USERID YOUR_PASSWORD {
/nzbget
/sonarr
/radarr
}

proxy /nzbget YOUR_NAS_LOCALIP:6789
proxy /sonarr YOUR_NAS_LOCALIP:8989
proxy /radarr YOUR_NAS_LOCALIP:7878
redir / /sonarr # Root will take to Sonarr
redir /synology https://synology.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X
}

nzbget.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
redir /nzbget/
}

sonarr.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
redir /sonarr/
}

radarr.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
redir /radarr/
}

synology.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
basicauth / YOUR_USERID YOUR_PASSWORD
proxy / YOUR_NAS_LOCALIP:5000
}

49

I’ll bet it’s not open (if it was, it’d probably have been because you opened it, and you’d know). But you could grab nmap and run nmap -p 5000 YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X and see if it comes back with a result, if you wanted to double check.

Actually, looking over, a few things…

1.

redir /synology https://synology.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X

Instead of this structure, in my Caddyfile above you’ll see I went with

example.com/subdomain {
  redir / https://subdomain.example.com
}

The reason being that the former won’t catch example.com/subdomain/ (only example.com/subdomain, no trailing slash), whereas the latter catches both (and anything else, e.g. example.com/subdomain/foo/bar). This one’s up to you if you care about that.

2.

I know I told you earlier to redir / /sonarr, but I’ve got a feeling that’s going to win over everything else and cause a redirect loop, because the form redir / is a catch-all and

So you might need to use this structure instead, so only requests for EXACTLY / get redirected:

redir 301 {
  if {path} is /
  to /sonarr
}

3.

radarr.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
  redir /radarr/
}

This structure is a redirect loop. /radarr/ is relative so it never breaks out of the subdomain, redirecting forever. You want this instead:

radarr.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
  redir YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X/radarr/
}

Or just ditch those three redir blocks entirely and don’t hand out service.example.com style subdomains (except for synology).

1 Like
50

Thank you!

I was really tempted to do it all using the subdomain style so I don’t have to walk all the readers through adding URL bases. Oh well, this is more simple, and its not too difficult to add URL base.

OK, I think I’ve incorproated everything! one last look?

YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
  tls YOUR_EMAIL@YOUR_EMAIL_PROVIDER.X
  errors stdout
  log stdout
  gzip

header / {
Strict-Transport-Security “max-age=31536000; includeSubDomains; preload”
X-XSS-Protection “1; mode=block”
X-Content-Type-Options “nosniff”
X-Frame-Options “DENY”
}

basicauth YOUR_USERID YOUR_PASSWORD {
/nzbget
/sonarr
/radarr
}

proxy /nzbget YOUR_NAS_LOCALIP:6789
proxy /sonarr YOUR_NAS_LOCALIP:8989
proxy /radarr YOUR_NAS_LOCALIP:7878

Root will take to Sonarr

redir 301 {
if {path} is /
to /sonarr
}
}

synology.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X {
basicauth / YOUR_USERID YOUR_PASSWORD
proxy / YOUR_NAS_LOCALIP:5000
}

Additional option just in case URL base used by mistake

YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X/synology {
redir / https://synology.YOUR_DDNS_NAME.YOUR_DDNS_PROVIDER.X
}

51

Still possible to do this subdomain style, if that’s what you want, but instead of removing the redir blocks, you’d need to change them to proxies (and change the proxies up above into redir blocks).

Again I’m a big fan of subfolders for apps that play nice, because I can basicauth the lot and enter my credentials once when I access any of them.

Cool, pretty much spot on. Fire it up, maybe with http:// first, run through the sites and make sure it all behaves like you expect.

1 Like
52

I created a whole new container, this time using the slim caddyfile without a common.conf.

The synology no longer works. It says 502 bad gateway.

I didn’t test this on the prior setup, but, when I access just my root, it does not route to sonarr. It actually goes to that generic page that says my caddy server is working. I thought we had killed all php etc?

53

Caddy doesn’t have a generic page saying that it works (unless you make one and serve it). You might be looking at the abiosoft/caddy default page (caddy-docker/index.html at master · abiosoft/caddy-docker · GitHub), which implies you’ve missed your Caddyfile somewhere and the container is still using the default.

54

Yes! That’s the page that loads! Sonarr, Radarr, and nzbget work fine thru their URL bases with the basicauth though, so it must be using my Caddyfile, right? I also grabbed the image and created a new container. What does that mean? There’s default code in abisoft that always has this page?? I am combing through their page to see if any clues:
abiosoft caddy

I figured out why my synology proxy didn’t work. I still had YOUR_NAS_LOCALIP orry. Its in my local copy, but my server copy was missing it. Must have copied to NAS before I saved. Sorry about that, but glad it was simple user error on my part.

55

I was halfway through typing a reply when I realised the error… My fault again, actually. The redir I gave you is incorrect. Use

redir 301 {
  if {path} is /
  / /sonarr
}

instead. redir takes the form [from] [dest], so previously it was only redirecting on requests for to, which would never happen (because of the conditional requiring the request to be for /). It effectively invalidated itself. I had it confused with the rewrite form of to [dest].

Also, your Caddyfile doesn’t declare a root, so Caddy assumes the PWD is the web root. You haven’t changed the container’s working directory, and you haven’t mounted anything over the top, so the container’s default /srv/index.html is still there.

This explains why, when receiving a request for /, Caddy serves the container’s default page from the static fileserver.

Man… iterative Caddyfile development, I tell you what.