caddyserver / caddyserver/cache-handler
How to use with reverse_proxy? (caching is not working)
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 393
- Forks
- 28
- Avg merge
- 32m
- Merged PRs (30d)
- 1
Description
Hi, I'm trying to use Caddy to cache .m3u8 files when reverse proxying to an upstream server. I’m using the cache directive and set up my Caddyfile as follows:
{
order cache before rewrite
order cache before reverse_proxy
cache {
allowed_http_verbs GET POST
ttl 60s
timeout {
backend 20s
cache 100ms
}
}
}
:9991 {
route /ch1/* {
@m3u8_files {
path_regexp m3u8 ^/.*\.m3u8(\?.*)?$
}
handle @m3u8_files {
header +X-Custom-Header "Some Value"
}
cache @m3u8_files {
ttl 60s
}
uri strip_prefix /ch1
rewrite * /ChannelOne{uri}
reverse_proxy https://upstream-host.me {
header_up Host {http.reverse_proxy.upstream.hostport}
}
}
}
What’s working:
- The
X-Custom-Headeris successfully added to the.m3u8responses. - The reverse proxy is functioning and serving content.
What’s not working:
- The caching doesn't seem to take effect at all. I expected
.m3u8files to be cached for 60 seconds, but every request still hits the upstream server.
Any help or guidance would be appreciated. Thanks in advance!
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the provided Caddyfile and reproduce requests to the .m3u8 matcher while observing whether the cache directive or reverse_proxy handles them. Review the cache-handler behavior around directive ordering, matchers, and cache keys; done means identifying the cause of the upstream request on every call and documenting a verified configuration or required change.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend, performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100