caddyserver / caddyserver/cache-handler

How to use with reverse_proxy? (caching is not working)

Open
#121 1 comment 0 reactions 0 assignees View on GitHub

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-Header is successfully added to the .m3u8 responses.
  • The reverse proxy is functioning and serving content.

What’s not working:

  • The caching doesn't seem to take effect at all. I expected .m3u8 files 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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.