Caddy v2 - update and warning

[Troymz 1]

Your first command works for me. But once i exit the command window and then run caddy run it does not work

 

here is my caddy file

{
    email ******@gmail.com
}

emby.mydomain.com {   
        
    }
    log {
        output file C:\caddy\logs\emby_access.log {
            roll true                # Rotate logs, enabled by default
            roll_size_mb 10            # Set max size X MB
            roll_gzip true            # Whether to compress rolled files
            roll_local_time true    # Use localhost time
            roll_keep 3                # Keep at most X log files
            roll_keep_days 7        # Keep log files for X days 
        }
    }
    encode gzip    
    reverse_proxy https://192.168.2.109:8096 {
        header_up X-Real-IP {remote_host}
    }
    
    reverse_proxy /movies/* https://radarr.mydomain.com {
        header_up Host {upstream_hostport}
        header_up X-Forwarded-Host {host}
    }
    redir /movies /movies/
    
    reverse_proxy /tv/* https://sonarr.mydomain.com {
        header_up Host {upstream_hostport}
        header_up X-Forwarded-Host {host}
    }
    redir /tv /tv/

}

 

I'd also like caddy to cover my **arr setups as well if possible.

 

Thanks

Edited August 30, 2022 by Troymz

[seanbuff 840]

I would suggest stripping it all back initially to ensure you get the core functionality working first. Some of your config format doesn't look correct. Try getting just Emby working first, something like this for now:
 

{
    email ******@gmail.com
}

#Emby
emby.mydomain.com {   
    encode gzip    
    reverse_proxy 192.168.2.109:8096
}

If you aren't running caddy via a service, you'll need to keep the command window open for it to continue to run.

[Troymz 1]

3 hours ago, seanbuff said:

I would suggest stripping it all back initially to ensure you get the core functionality working first. Some of your config format doesn't look correct. Try getting just Emby working first, something like this for now:
 

{
    email ******@gmail.com
}

#Emby
emby.mydomain.com {   
    encode gzip    
    reverse_proxy 192.168.2.109:8096
}

If you aren't running caddy via a service, you'll need to keep the command window open for it to continue to run.

Okay, this is working via the caddy run command.

 

How would I go about adding my ***arr's?

Just to confirm.. my emby network settings are: 

Local http: 8096 Local https: 8920 Public http 80 Public https 443 External domain: emby.mydomain.com Secure connections handled by reverse proxy. Disabled automatic port mapping.

 

As for service is it the NSSM way?

[seanbuff 840]

4 minutes ago, Troymz said:

Local http: 8096 Local https: 8920 Public http 80 Public https 443 External domain: emby.mydomain.com Secure connections handled by reverse proxy. Disabled automatic port mapping.

Yep looks good. As long as you've port forwarded 80 and 443 to your Caddy host in your router.

 

4 minutes ago, Troymz said:

As for service is it the NSSM way?

NSSM is one way, and seems to work no problem.
There's also the other method that Caddy documents here using WinSW: https://caddyserver.com/docs/running#windows-service

 

6 minutes ago, Troymz said:

How would I go about adding my ***arr's?

Once you are happy with Emby's config, you would simply duplicate that and replace appropriately for the other services, eg:

#Emby
emby.mydomain.com {   
    encode gzip    
    reverse_proxy 192.168.2.109:8096
}

#Sonarr
sonarr.mydomain.com {   
    encode gzip    
    reverse_proxy <Sonarr IP>:<Port>
}

#Radarr
radarr.mydomain.com {   
    encode gzip    
    reverse_proxy <Radarr IP>:<Port>
}

 

[Troymz 1]

3 hours ago, seanbuff said:

Once you are happy with Emby's config, you would simply duplicate that and replace appropriately for the other services, eg:

#Emby
emby.mydomain.com {   
    encode gzip    
    reverse_proxy 192.168.2.109:8096
}

#Sonarr
sonarr.mydomain.com {   
    encode gzip    
    reverse_proxy <Sonarr IP>:<Port>
}

#Radarr
radarr.mydomain.com {   
    encode gzip    
    reverse_proxy <Radarr IP>:<Port>
}

 

Okay running as a service. Thank you!!

This is my caddyfile now.. but the ***arrs do not work. What am I missing? I have restarted the service after saving the caddyfile.

{
	email *****@gmail.com
}

#Emby
emby.mydomain.com {   
    encode gzip    
    reverse_proxy 192.168.2.109:8096
}
#Sonarr
sonarr.domain.com {   
    encode gzip    
    reverse_proxy 192.168.2.109:8989
}

#Radarr
radarr.domain.com {   
    encode gzip    
    reverse_proxy 192.168.2.109:7878
}

 

Edited August 30, 2022 by Troymz

[seanbuff 840]

Have you configured your DNS provider of your domain name for the additional services?

sonarr.domain.com
radarr.domain.com

either CNAME records pointing to your A record?

Sorry I have no experience with those *arr services, but I run others behind Caddy and the idea is the same.

[Troymz 1]

3 hours ago, seanbuff said:

Have you configured your DNS provider of your domain name for the additional services?

sonarr.domain.com
radarr.domain.com

either CNAME records pointing to your A record?

Sorry I have no experience with those *arr services, but I run others behind Caddy and the idea is the same.

Ok that seems to be what it was. Radarr is working but Sonarr only works when i manually go into command and type caddy run.  As soon as I exit that and start the caddy service in task manager it no longer works stating This site can’t provide a secure connection. But Radarr continues to work alongside emby. Any ideas?

 

Edit: Nevermind, as soon as I posted this it started working.  Thank you so much for all your help!

Edited August 30, 2022 by Troymz

[pwhodges 1527]

By default "encode" acts on pretty much just text and javascript.  The overwhelming data in emby is video which will be unaffected - so adding "encode gzip" to the Emby configuration is a waste of time (and harmless, I guess).

Paul

[kikinjo 162]

hey @pwhodges

Just wondering, are your connections on caddy http/2 ? I see all connections comming from caddy to emby are http1.1. any way to force http/2 ?

[pwhodges 1527]

I'm using Caddy v2.61, and Opera and Firefox both connect using http/3 (which Caddy selects as default from v2.6 onward).

I guess some clients might be restricted to earlier protocols, but Caddy sure isn't.

Paul

[pwhodges 1527]

PS: note that http/3 requires UDP, and will fall back to http/2 if the firewall is blocking it.

Paul

[Q-Droid 641]

3 hours ago, kikinjo said:

hey @pwhodges

Just wondering, are your connections on caddy http/2 ? I see all connections comming from caddy to emby are http1.1. any way to force http/2 ?

Does Emby itself support http/2 over non-TLS?

[Luke 37060]

3 hours ago, Q-Droid said:

Does Emby itself support http/2 over non-TLS?

I'd have to check but I think we have it enabled only for ssl.

[pwhodges 1527]

4 hours ago, chef said:

maybe it's not even worth it. 

Configuring Caddy is so easy that installing and running an Emby plugin to do it would be essentially as much effort.

Paul

[kikinjo 162]

On 1/8/2023 at 2:13 PM, pwhodges said:

I'm using Caddy v2.61, and Opera and Firefox both connect using http/3 (which Caddy selects as default from v2.6 onward).

I guess some clients might be restricted to earlier protocols, but Caddy sure isn't.

Paul

Thanx Paul. I m also on latest version, but i see browser and all clients connection all over http 1. Interesting.

[rbjtech 4257]

On 08/01/2023 at 16:00, Q-Droid said:

Does Emby itself support http/2 over non-TLS?

I'm also interested in this - I asked the same question on the NGINX thread .. 

 

 

Edited January 13, 2023 by rbjtech

[Q-Droid 641]

The caddy log should show the startup listening for http/3 and the connections to caddy in http/2 or /3. Unless you're running with end-to-end encryption the emby log will show connections as http/1.

Edited January 13, 2023 by Q-Droid

[rbjtech 4257]

1 minute ago, Q-Droid said:

The caddy log should show the startup listening for http/3 and the connections to caddy in http/2 or /3. Unless you're running with end-to-end encryption the emby sessions will be http/1.

Yep - with you there - I think even with a RP it has to be end-end - as the RP would need to convert http2/3 to 1.1 which clearly it cannot do.

[kikinjo 162]

3 hours ago, Q-Droid said:

The caddy log should show the startup listening for http/3 and the connections to caddy in http/2 or /3. Unless you're running with end-to-end encryption the emby log will show connections as http/1.

I m running Caddy https tls client -> caddy , after that no encryption to emby server. Will check logs to see the listeners if there are any...

[chef 3745]

29 minutes ago, kikinjo said:

I m running Caddy https tls client -> caddy , after that no encryption to emby server. Will check logs to see the listeners if there are any...

Did you reverse proxy the server IP properly with the route command?

[chef 3745]

@Lukeaswain check this thread out.

Comment and follow the thread.

We may be able to help, or we may need assistance.

[pwhodges 1527]

1 hour ago, chef said:

Did you reverse proxy the server IP properly with the route command?

What do you mean?  A typical Caddy reverse-proxy doesn't need to use the route directive (in fact none of my dozen or so websites uses it either).

Paul

[chef 3745]

22 minutes ago, pwhodges said:

What do you mean?  A typical Caddy reverse-proxy doesn't need to use the route directive (in fact none of my dozen or so websites uses it either).

Paul

Oh, okay. I thought it needed "route /*". 

[chef 3745]

Paul, have you ever seen this error at the end of the caddy startup?

An attempt was made to access a socket in a way forbidden by its access permissions.

Edited January 13, 2023 by chef

[pwhodges 1527]

No, sorry.  But I haven't used it on Linux, which is what I tend to associate the term "socket" with.

Re "route" - that's not what it is.  Route is a directive to force a group of other directives to be handled in the order you write them rather than their default order.  What I think you're trying to write with it is what's called a "matcher", which can be part of many directives - but in almost all cases "/*" is the default anyway.  The route directive can have a matcher, but this is used to specify that the directives it controls are only used in that instance, and you might typically have multiple routes to specify different subsections of a web site.  But for that purpose you would normally use "handle", which also specifies a group of directives to be used in just some of the web site, but doesn't force an order to override the default order on them as route does.

Paul

Edited January 13, 2023 by pwhodges