Errors with v2's reverse_proxy to remote domain

Help
1

1. Caddy version (caddy version):

2.3.0

2. How I run Caddy:

Docker, using Cloudflare as DNS on rviewit.com

a. System environment:

Ubuntu 18.04.1 LTS, Docker 18.06

b. Command:

docker-compose -f /etc/hasura/docker-compose.yaml up -d

c. Service/unit/compose file:

services:
  caddy:
    image: caddy/caddy:alpine
    depends_on:
    - "graphql-engine"
    restart: always
    ports:
    - "80:80"
    - "443:443"
    volumes:
    - ./Caddyfile:/etc/caddy/Caddyfile
    - caddy_certs:/root/.caddy
    - caddy_data:/data
volumes:
  db_data:
  caddy_certs:
  caddy_data:

d. My complete Caddyfile or JSON config:

api.revddit.com {
    tls internal
    route /q/* {
        uri strip_prefix q/
        reverse_proxy 172.17.0.1:9090
    }
}

rviewit.com {
    tls internal
#	log {
#		format json
#		output stdout
#	}
    route /api/short/modlogs/* {
        uri strip_prefix api/short/modlogs/
        header Access-Control-Allow-Origin *
        reverse_proxy * modlogs.fyi {
            header_up Host {http.reverse_proxy.upstream.hostport}
        }
    }
    route /api/short/* {
        uri strip_prefix api/short/
        reverse_proxy 172.17.0.1:8383
    }
    route /api/long/* {
        uri strip_prefix api/long/
        reverse_proxy 172.17.0.1:8383
    }
    route /api/* {
        uri strip_prefix api/
        reverse_proxy 172.17.0.1:8383
    }
}

3. The problem I’m having:

Requests matching the first route return status 400, for example this request

4. Error messages and/or full log output:

{
  "level": "error",
  "ts": 1618132717.0355983,
  "logger": "http.log.access.log0",
  "msg": "handled request",
  "request": {
    "remote_addr": "",
    "proto": "HTTP/1.1",
    "method": "GET",
    "host": "rviewit.com",
    "uri": "/api/short/modlogs/api/subreddits",
    "headers": {
      "Cf-Ray": [
        "63e320e8ec355ef1-SJC"
      ],
      "Sec-Ch-Ua": [
        "\"Google Chrome\";v=\"89\", \"Chromium\";v=\"89\", \";Not A Brand\";v=\"99\""
      ],
      "Sec-Fetch-Site": [
        "none"
      ],
      "Sec-Fetch-Dest": [
        "document"
      ],
      "Cf-Connecting-Ip": [
        ""
      ],
      "Cf-Request-Id": [
        "0961d2e59200005ef134394000000001"
      ],
      "Accept-Encoding": [
        "gzip"
      ],
      "Dnt": [
        "1"
      ],
      "User-Agent": [
        "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.114 Safari/537.36"
      ],
      "Connection": [
        "Keep-Alive"
      ],
      "X-Forwarded-For": [
        ""
      ],
      "X-Forwarded-Proto": [
        "https"
      ],
      "Cf-Visitor": [
        "{\"scheme\":\"https\"}"
      ],
      "Sec-Ch-Ua-Mobile": [
        "?0"
      ],
      "Upgrade-Insecure-Requests": [
        "1"
      ],
      "Accept": [
        "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9"
      ],
      "Sec-Fetch-User": [
        "?1"
      ],
      "Accept-Language": [
        "en"
      ],
      "Cookie": [
        "__cfduid=db7c2d62c2cee927bc9cd06c698a657e41615882696"
      ],
      "Cdn-Loop": [
        "cloudflare"
      ],
      "Sec-Fetch-Mode": [
        "navigate"
      ]
    },
    "tls": {
      "resumed": false,
      "version": 772,
      "cipher_suite": 4865,
      "proto": "",
      "proto_mutual": true,
      "server_name": "rviewit.com"
    }
  },
  "common_log": "162.158.255.131 - - [11/Apr/2021:09:18:37 +0000] \"GET /api/short/modlogs/api/subreddits HTTP/1.1\" 400 155",
  "duration": 0.011514512,
  "size": 155,
  "status": 400,
  "resp_headers": {
    "Cf-Ray": [
      "-"
    ],
    "Date": [
      "Sun, 11 Apr 2021 09:18:37 GMT"
    ],
    "Content-Type": [
      "text/html"
    ],
    "Server": [
      "Caddy",
      "cloudflare"
    ],
    "Access-Control-Allow-Origin": [
      "*"
    ],
    "Content-Length": [
      "155"
    ]
  }
}

5. What I already tried:

Other incarnations of reverse_proxy in Caddyfile,

reverse_proxy modlogs.fyi
reverse_proxy https://modlogs.fyi:443
...

I read this post’s answer and adjusted it to use header_up Host as shown above. However, I still get errors. I wonder if it has to do with tls or not.

It was working under Caddy v1, where my Caddyfile was,

http://rviewit.com, https://rviewit.com {
  proxy /api/short/modlogs/ https://modlogs.fyi {
    without /api/short/modlogs
  }

Maybe it has something to do with the tls internal directive?

6. Links to relevant resources:

2

You should be using the caddy image, not caddy/caddy. The latter is our CI target, not the official images.

This path isn’t correct, Caddy doesn’t store anything there in v2. It’s a path from v1.

Please see the docs on Docker

You can replace route + uri strip_prefix with simply the handle_path directive which has path stripping built in.

I don’t think you’re stripping the path correctly. You need the leading /. Using handle_path instead avoids this problem because it deals with that for you, reduces the configuration surface avoiding mistakes like that.

1 Like
3

Hi @francislavoie, thank you for your reply. I’ve made the suggested adjustments and now receive a response!

Now for the request the response comes via a redirect. Is it possible to do this without the redirect being passed to the client? That way I can cache the response I want. These topics may be related,

I did not notice any redirect happening with the Caddy v1 configuration. Here is the updated config,

services:
  caddy:
    image: caddy:2.3.0
    depends_on:
    - "graphql-engine"
    restart: always
    ports:
    - "80:80"
    - "443:443"
    volumes:
    - ./Caddyfile:/etc/caddy/Caddyfile
    - caddy_data:/data
    - caddy_config:/config
volumes:
  db_data:
  caddy_data:
  caddy_config:

api.revddit.com {
    tls internal
    handle_path /q/* {
        reverse_proxy 172.17.0.1:9090
    }
}

rviewit.com {
    tls internal
    handle_path /api/short/modlogs/* {
        header Access-Control-Allow-Origin *
        reverse_proxy modlogs.fyi {
            header_up Host {http.reverse_proxy.upstream.hostport}
        }
    }
    handle_path /api/short/* {
        reverse_proxy 172.17.0.1:8383
    }
    handle_path /api/long/* {
        reverse_proxy 172.17.0.1:8383
    }
    handle_path /api/* {
        reverse_proxy 172.17.0.1:8383
    }
}
4

Nope, not possible. If your upstream app is serving a redirect, there’s nothing Caddy can do to stop it.

See this article for details; I highly recommend using subdomains for each app instead of subpaths.

5

Actually I think what’s happening is modlogs is performing an HTTP->HTTPS redirect, because you made your first request over HTTP. Use https://modlogs.fyi as your proxy address instead, that might work.

1 Like
6

That was it! Thank you so much :smiley:

7

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