Jump to content

Caddy v2 - update and warning


pwhodges

Recommended Posts

Hey !

 

For log you can do this

(logging) {
	log {
		output file /logs/{args.0}.log {
			roll_size 10mb
			roll_keep 3
			roll_keep_for 72h
		}
		format filter {
			wrap console
			fields {
				request>headers>Authorization delete
			}
		}
	}
}


emby.domain.com {
	import logging emby
	/* [...] */
}

sonarr.domain.com {
	import logging sonarr
	/* [...] */
}

radarr.domain.com {
	import logging radarr
	/* [...] */
}

And you will have 3 separate log files for each reverse proxy

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

justinrh
On 2/9/2023 at 12:36 PM, Bagul said:

And you will have 3 separate log files for each reverse proxy

I couldn't get this to work.  I'm using Windows.  Is the syntax viable only for Linux or something?  This block goes after the top-most block, I presume.

Link to comment
Share on other sites

pwhodges

Caddy syntax doesn't vary between systems (though note that this is only for Caddy v2 - anyone using v1 should know well by now that many features have changed).

As it happens, I've never bothered with a snippet like this; but looking at the excellent Caddy documentation on snippets:
https://caddyserver.com/docs/caddyfile/concepts#snippets
suggests to me that the example above is missing quotes around the parameters of the imports.

Paul

Link to comment
Share on other sites

1 hour ago, justinrh said:

I couldn't get this to work.  I'm using Windows.  Is the syntax viable only for Linux or something?  This block goes after the top-most block, I presume.

The path for the output file directive has to be changed on your side, in my case only.But otherwise, it works for me.

The snippet "(logging){}" must be outside a block

23 minutes ago, pwhodges said:

Caddy syntax doesn't vary between systems (though note that this is only for Caddy v2 - anyone using v1 should know well by now that many features have changed).

As it happens, I've never bothered with a snippet like this; but looking at the excellent Caddy documentation on snippets:
https://caddyserver.com/docs/caddyfile/concepts#snippets
suggests to me that the example above is missing quotes around the parameters of the imports.

Paul

I think in the example of the documentation the inverted commas are there because there are several words. I never put inverted commas.

Link to comment
Share on other sites

  • 1 month later...
Gecko

Small update about the Caddy Subject. I was running into issues while outside my home network on my iPhone. So I checked on my browser's dev tools why the heck I was having multiple seconds of delay before getting any response from Emby or even no response at all (Navigation through the list of thumbnails was really a pain with lot's of images not loading at all).

Turns out (at least in the latest iOS's Safari), the protocol being used is http3 and not http2 anymore (since when? IDK). But this protocol introduce a lot of "lag" in every response I got though Caddy. So I tested by restricting the protocols to h1 and h2 only and the issue magically disappeared ! :)

Like discussed before, http/1.1 is even a little bit faster than http2, so I went all the way down to restrict only h1 in my Caddyfile using the Global options block.

{
	servers :80 {
           protocols h1
	}

	servers :443 {
           protocols h1
	}
}

Hope this help anyone having the same issue.

Link to comment
Share on other sites

pwhodges

Curious...  Have you raised this on the Caddy forums?  Do you keep up with the latest Caddy version?

EDIT:  I just tested using Safari on the iPhone (on the LAN, and also remotely), and I am getting no delays at all - it's working as crisply as I expect.

Paul

Edited by pwhodges
Link to comment
Share on other sites

rbjtech

Could be other end-end devices rejecting QUIC/UDP (what http3 uses) or putting them at lower priority, thus you losing data ?

I'm surprised http1 is faster than http2 over a remote connection though (for emby) - that is interesting. 

I would also be a little cautions forcing http1 - as TLS/SSL is 'optional' for this protocol - thus you may be compromising some security if using TLS.

Edited by rbjtech
Link to comment
Share on other sites

Gecko

@pwhodges, on LAN, i also don't have any delay at all. I updated caddy a few days ago, so I'm on the latest version yes.

@rbjtech, what would you suggest to not compromise security ? Caddy redirects any http requests to their https equivalent before processing anything but I can activate h2 on the downstream and keep h1 for the upstream connection with Emby ?

This is what the caddy documentation has to say about protocols. That's the last sentence that made me try forbidding h3

protocols

The space-separated list of HTTP protocols to support. Default: h1 h2 h3. Accepted values are:

h1 for HTTP/1.1
h2 For HTTP/2
h2c for HTTP/2 over cleartext
h3 for HTTP/3
Currently, enabling HTTP/2 (including H2C) necessarily implies enabling HTTP/1.1 because the Go standard library does not let us disable HTTP/1.1 when using its HTTP server. However, either HTTP/1.1 or HTTP/3 can be enabled independently.

Note that H2C ("Cleartext HTTP/2" or "H2 over TCP") and HTTP/3 are not implemented by the Go standard library, so some functionality or features may be limited. We recommend against enabling H2C unless it is absolutely necessary for your application.

 

Link to comment
Share on other sites

pwhodges

I realised later you were saying it was remote, and did a remote test which was absolutely fine as well - in fact a positively good result seeing as I have a poor mobile signal at home to the extent that the phone switches to wi-fi mode for calls.

I wonder if your phone network has an issue with http/3.  

Paul

Link to comment
Share on other sites

rbjtech
14 minutes ago, Gecko said:

@rbjtech, what would you suggest to not compromise security ? Caddy redirects any http requests to their https equivalent before processing anything but I can activate h2 on the downstream and keep h1 for the upstream connection with Emby ?

For Internet to Caddy - Stick with http2 using TLS 1.2 or 1.3 only.

Caddy to Emby doesn't really matter if it's your private LAN.  Performance (should..) not be an issue on the LAN, http is perfectly acceptable.

Link to comment
Share on other sites

  • 2 weeks later...
Bagul

Hello to all,

I made a configuration for goaccess and caddy with a real time visual.

For those who don't know goaccess it's a tool coded in C that allows visualization and analysis of log.

I took the Docker container here original repo and I updated it.

Link: my repo

For the configuration of the container:

version: '3.3

services:
    goaccess:
        image: bagul/goaccess
        container_name: goaccess
        ports:
            - '7889:7889'
        volumes:
            - '/path/to/host/nginx/logs:/opt/log'
            - '/path/to/goaccess/storage:/config'


Caddy logs must be in json format

 

And the goaccess configuration:

 

log-format CADDY

config-dialog false
hl-header true
json-pretty-print false
no-color false
no-column-names false
no-csv-summary false
no-progress false
no-tab-scroll false
with-mouse false
real-time-html true

log-file /opt/log/log_file1.log
log-file /opt/log/log_file2.log

agent-list false
with-output-resolver false
exclude-ip 127.0.0.1
exclude-ip 192.168.0.1-192.168.0.254
exclude-ip 192.168.1.1-192.168.1.254
exclude-ip 192.168.4.1-192.168.4.254
http-method yes
http-protocol yes
output /config/html/index.html
no-query-string false
no-term-resolver false
444-as-404 false
xx-to-unique-count false
all-static-files false
double-decode false
ignore-crawlers false
crawlers-only false
ignore-panel REFERRERS
ignore-panel KEYPHRASES
real-os true

static-file .css
static-file .js
static-file .jpg
static-file .png
static-file .gif
static-file .ico
static-file .jpeg
static-file .pdf
static-file .csv
static-file .mpeg
static-file .mpg
static-file .swf
static-file .woff
static-file .woff2
static-file .xls
static-file .xlsx
static-file .doc
static-file .docx
static-file .ppt
static-file .pptx
static-file .txt
static-file .zip
static-file .ogg
static-file .mp3
static-file .mp4
static-file .exe
static-file .iso
static-file .gz
static-file .rar
static-file .svg
static-file .bmp
static-file .tar
static-file .tgz
static-file .tiff
static-file .tif
static-file .ttf
static-file .flv
geoip-database /usr/local/share/GeoIP/GeoLite2-City.mmdb

 

Edited by Bagul
  • Thanks 1
Link to comment
Share on other sites

  • 2 months later...
Gecko

@Bagulthat's really nice, thank you !

 

About my previous issues with http3, I moved caddy from a pi4 to a more powerful toy and all my issues are now ancient history.

Reverse Proxy is rock solid and Emby has never been so fast even if I still don't know what was the issue with the pi...

  • Thanks 1
Link to comment
Share on other sites

  • 5 months later...
On 04/05/2020 at 14:27, pwhodges said:

OK, I have run an initial trial of Caddy version 2, and it works as simply as they say it should.  I used Caddy 2 rc3 for the trial.  Note that you can no longer get Windows binaries of Caddy v1, only source, so v2 is where it's at now!

 

First, the setup I tried it in, and the assumptions I made.  A domain name is required for external access; you need to get that and specify your IP address in the DNS.  I use ports 80 and 443 for Caddy, because this enables it to get the required certificate from Let's Encrypt; it does this completely automatically in most circumstances, but you must have port 80 open for the process to work.  When you try to access port 80, however, Caddy automatically redirects the request to port 443 - again, you don't need to configure this or think about it.  So, I open ports 80 and 443 in my router to the machine running Caddy (and in the router's firewall as well, if this is a separate action), and ensure that the Windows firewall will also allow these ports through to caddy.exe.

 

Next, I am running Emby in another machine, which for this example has IP address 192.168.1.66.  I leave its ports as default, and only use the http one (8096).  As it's on a different machine I could change this to port 80 for convenience, but I don't bother for other reasons.

 

For an initial test, I went to the directory where I had dropped the Caddy executable and in a command window in the directory containing Caddy typed the command:

caddy reverse-proxy --from emby.mydomain.com --to http://192.168.1.66:8096

That's it - the first time it may take a little while to get the certificate organised, but subsequent runs will be almost instant, as the certificate is already in place.  The command doesn't return, so the window needs to be preserved while Caddy is running in this manner.  Then simply typing emby.mydomain.com in a browser shows me what I expect.  Note, I use the external domain name for internal access as well - this means that I can set up mobile devices to work whether I am at home or away.  This does require a router that will loop back internal requests to the outside address efficiently, though; my Draytek Vigor does this perfectly.

 

Finally I tried a config file for Caddy which enables running in the background or as a service (I haven't checked setting Caddy 2 up as a Windows service yet, which is how I'm running Caddy v1).

 

This went as follows: in the same directory as caddy.exe I created a file called caddyfile (no extension).  In this I placed the following text:

{
    email name@maildomain.com
}

emby.mydomain.com {
    reverse_proxy http://192.168.1.66:8096
}

Note the underscore in "reverse_proxy" where the command line version had a dash.  If you can't find how to edit a file without an extension, create it with ".txt" and then delete the extension after editing it.  The email directive enables Let's Encrypt to email you warnings if problems arise in the future.  If Caddy is started in the directory containing the exe file and caddyfile, it will automatically use the specified configuration.  I first simply ran it in the command window using the following command:

caddy run

As before, this does not return, and the proxy is now operating.  It is also possible to start Caddy in the background from a command, thus:

caddy start

In this case you can stop it using the command:

caddy stop

which is rather unsurprising.  If you ran caddy using the previous commands which held the window without returning, Ctrl-C will stop it in the usual manner, as will closing the window, or using the "caddy stop" command in another window.

 

At least in my system, this really is all it takes for the proxy to work and do all the things required.  But Caddy can be extensively customised if other systems require tweaks.  There is even a facility to give it an nginx config file which it should then translate internally, but as I don't use nginx, I'm not going to try that out - in any case, it would take as much typing to specify that as to provide the trivially simple Caddy commands that work.

 

Paul

You legend, thank you. I first attmpeted SSL on my server months ago with no luck. Recently moved house an discovered I'd been put on CGNAT, fortunately that got resolved. But been hitting road block after road block this last week trying various guides and YT video - absolute nightmare. And then this morning - your post solved it. Danke. 

  • Thanks 1
Link to comment
Share on other sites

So now that's working, I need to make run as a service in the background. I think I just follow/add on the below guide for Caddy v2? 

Quote

 

If you want, you can also run Caddy as a service, it'll start automatically with your computer even if you're not logged in, and it will be invisible, so no annoying command window always there.  If you downloaded Caddy with the hook.service plug-in then it's easy.  First open a CMD window, change to your caddy directory (cd c:\caddy) and run this command to install the service.  You have to run these commands as an administrator, so when you run CMD, right click and choose "Run as Administrator."

caddy -service install -agree -email "myemail@email.com" -conf "c:\caddyfile.txt" -log "c:\caddylog.txt"

You'll notice it's the same as what you ran before to start Caddy, but with -service install added, and with -log c:\caddylog.txt added.  If you click run, type "services" and start the Services control panel, you'll now see Caddy listed as a service but it will not be running.  Now run the command:

caddy -service start 

That's it.  In the Services control panel you'll see that the Caddy service is running.  You only have to do this once, when you reboot it'll automatically start the service again for you.  You can look at the caddylog.txt file to see the running status, and you can always check the Services control panel to verify it's running.

 

 

Link to comment
Share on other sites

pwhodges

Personally I use nssm to set up the service (it gives you a GUI for configuration, and the tab remind you of things like choosing the logic user).  Instructions for using nssm to start Emby are here, and the parallel for Caddy should be clear enough.

I could fill this out in detail in a while, but I'm just starting to be busy cooking right now.

Paul

Link to comment
Share on other sites

  • 2 weeks later...
est3ban129

I have this error triyng to use Caddy..

I get this error when I try to play something, it plays but this error appears in Caddy

2023/11/16 10:15:54.696 ERROR   http.handlers.reverse_proxy     aborting with incomplete response       {"upstream": "localhost:8096", "duration": 0.022399, "request": {"remote_ip": "124.120.193.XXX", "remote_port": "3307", "client_ip": "124.120.193.XXX", "proto": "HTTP/2.0", "method": "GET", "host": "emb1.mypublicdomain.com", "uri": "/emby/videos/269145/original.mkv?DeviceId=ca5a2b89-75e4-4da7-92da-223c87cffe1d&MediaSourceId=8ee174b7dc1f83c5a8066856d3f9e6a5&PlaySessionId=34ce1c95f5644510900246251d749ca6&api_key=7fe0c8e1c14c442695bfe52a5988c799", "headers": {"Accept-Encoding": ["identity;q=1"], "Upgrade": [""], "X-Forwarded-For": ["124.120.193.72"], "If-Range": ["\"5c48811a6eafbe93d215093aae184e57\""], "Sec-Ch-Ua-Mobile": ["?0"], "Sec-Ch-Ua": ["\"Microsoft Edge\";v=\"119\", \"Chromium\";v=\"119\", \"Not?A_Brand\";v=\"24\""], "X-Forwarded-Proto": ["https"], "Dnt": ["1"], "Sec-Ch-Ua-Platform": ["\"Windows\""], "Accept-Language": ["es,es-ES;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6,th;q=0.5"], "Sec-Fetch-Mode": ["cors"], "Connection": [""], "Accept": ["*/*"], "X-Forwarded-Host": ["emb1.mypublicdomain.com"], "Sec-Gpc": ["1"], "Range": ["bytes=35778-2147519424"], "Referer": ["https://emb1.mypublicdomain.com/web/index.html"], "Sec-Fetch-Site": ["same-origin"], "User-Agent": ["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36 Edg/119.0.0.0"], "Sec-Fetch-Dest": ["video"]}, "tls": {"resumed": false, "version": 772, "cipher_suite": 4865, "proto": "h2", "server_name": "emb1.mypublicdomain.com"}}, "error": "writing: http2: stream closed"}

And i not doing nothing special.

caddy reverse-proxy --from emb1.mypublicdomain.com --to localhost:8096

 

 

Edited by est3ban129
Link to comment
Share on other sites

8 hours ago, est3ban129 said:

I have this error triyng to use Caddy..

I get this error when I try to play something, it plays but this error appears in Caddy

2023/11/16 10:15:54.696 ERROR   http.handlers.reverse_proxy     aborting with incomplete response       {"upstream": "localhost:8096", "duration": 0.022399, "request": {"remote_ip": "124.120.193.XXX", "remote_port": "3307", "client_ip": "124.120.193.XXX", "proto": "HTTP/2.0", "method": "GET", "host": "emb1.mypublicdomain.com", "uri": "/emby/videos/269145/original.mkv?DeviceId=ca5a2b89-75e4-4da7-92da-223c87cffe1d&MediaSourceId=8ee174b7dc1f83c5a8066856d3f9e6a5&PlaySessionId=34ce1c95f5644510900246251d749ca6&api_key=7fe0c8e1c14c442695bfe52a5988c799", "headers": {"Accept-Encoding": ["identity;q=1"], "Upgrade": [""], "X-Forwarded-For": ["124.120.193.72"], "If-Range": ["\"5c48811a6eafbe93d215093aae184e57\""], "Sec-Ch-Ua-Mobile": ["?0"], "Sec-Ch-Ua": ["\"Microsoft Edge\";v=\"119\", \"Chromium\";v=\"119\", \"Not?A_Brand\";v=\"24\""], "X-Forwarded-Proto": ["https"], "Dnt": ["1"], "Sec-Ch-Ua-Platform": ["\"Windows\""], "Accept-Language": ["es,es-ES;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6,th;q=0.5"], "Sec-Fetch-Mode": ["cors"], "Connection": [""], "Accept": ["*/*"], "X-Forwarded-Host": ["emb1.mypublicdomain.com"], "Sec-Gpc": ["1"], "Range": ["bytes=35778-2147519424"], "Referer": ["https://emb1.mypublicdomain.com/web/index.html"], "Sec-Fetch-Site": ["same-origin"], "User-Agent": ["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36 Edg/119.0.0.0"], "Sec-Fetch-Dest": ["video"]}, "tls": {"resumed": false, "version": 772, "cipher_suite": 4865, "proto": "h2", "server_name": "emb1.mypublicdomain.com"}}, "error": "writing: http2: stream closed"}

And i not doing nothing special.

caddy reverse-proxy --from emb1.mypublicdomain.com --to localhost:8096

 

 

This error is not generated by caddy directly, but by a "tool" (go's net/http lib). It's just that the client has closed the connection while transferring information. This isn't necessarily a problem if it doesn't cause any malfunction on your end. I've got it too.

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...