Reverse proxy from the path to the desired address

I am going to reverse proxy domainone.com/blog/ to https://domaintwo.com. The goal is to transform incoming requests as follows:

domainone.com/blog/	=>	https://domaintwo.com
domainone.com/blog/seo/	=>	https://domaintwo.com/seo/
domainone.com/blog/article/product/	=>	https://domaintwo.com/article/product/	

But the settings I applied in Caddyfile are not working properly.

domainone.com/blog/ {
    reverse_proxy https://domaintwo.com
}

Currently, the requests are incorrectly based on the config.yml above as follows:

domainone.com/blog/	=>	https://domaintwo.com/blog/
domainone.com/blog/seo/	=>	https://domaintwo.com/blog/seo/
domainone.com/blog/article/product/	=>	https://domaintwo.com/blog/article/product/	

I install Caddy 2 using docker. The latest version 2.7.6-alpine is installed and I installed it with the help of Docker Compose.
docker-compose.yml:

version: '3'

services:
  caddy:
    image: caddy:latest
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile

Please guide me. I have been searching on Google and asking questions from chatgpt for almost 4 days, but my problem is not solved.

It would be much better if you instead use a subdomain like blog.domainone.com. This article describes:

Also for proxying to an HTTPS upstream, see the docs: reverse_proxy (Caddyfile directive) — Caddy Documentation

Thank you for your reply. Yes, the problem is solved with a subdomain, but for some reason, I don’t want to use a subdomain. That’s why I was challenged and I’m looking for a solution.
Thank you for giving a solution with the help of path.

You might want to try:

domainone.com {
    handle_path /blog/* {
        reverse_proxy https://domaintwo.com {
            header_up Host {upstream_hostport}
        }
    }

The handle_path is described here: handle_path (Caddyfile directive) — Caddy Documentation

1 Like

@stbu that’s mentioned in the article I linked above.

But as that article mentions, that is often not a solution that will work, because if the upstream app ever crafts any paths in the HTML response, it may have the /blog prefix missing, breaking all URLs or causing JS/CSS assets to fail to load.

The upstream app must be aware of the path prefix being stripped, otherwise it can’t build paths correctly.

So that’s why subdomains are the recommended solution, because it avoids this problem entirely.