Forcing 404 or 302 on certain fixed upstream paths

1. Caddy version (caddy version):

v2.4.6 h1:HGkGICFGvyrodcqOOclHKfvJC0qTU7vny/7FhYp9hNw=

2. How I run Caddy:

a. System environment:


(strip-www) {
    @www.{args.0} host www.{args.0}
    redir @www.{args.0} https://{args.0}{uri}

(common-tls-example) {

    # HSTS (63072000 seconds)
    header Strict-Transport-Security "max-age=63072000"
} {
    import strip-www
    import common-tls-example
} {
    reverse_proxy http://internal_app:65
    import common-tls-example

I am serving an application (internal_app) at
I didn’t write this application and the page at should be inaccessible to the user (and return a 404 or 302 to /). There are 2 ways I can think of this path being created:

  1. accessed by the user (saved bookmark or history etc)
  2. generated by the application (eg: if user logs out, under certain scenarios, the app sends them to this page)

This is an update/fix that should be made in the application but until that’s done, I want to work around it. Is this possible through caddyfile?

I was reading the docs and I think it should be using the path matcher:

… but I am struggling to write the path matcher stanza.

  1. Is there a way to redir to / in case of 1 or 2?
  2. If not, atleast return a 404?

You can either do:

redir /some-path* /


respond /some-path* 404

Ok, so updating the last stanza to: {
    reverse_proxy http://internal_app:65
    import common-tls-example

    redir /should-be-inaccessible* /


Will have the following behavior:

  1. If the user tries to access:

They will be sent back to

  1. If the application was ever to expose this path to the user (like a redir on its own), the user won’t even notice the path (it won’t show up in their browser history etc)?


They could see the path. Caddy can’t control browser history.

1 Like

This topic was automatically closed after 30 days. New replies are no longer allowed.