I think i'm faced with a similar problem. Tried to set up a proxy chain - both on a local net. First one is caddy and the second is squid. I wanted to upstream form caddy to squid.

Caddyfile:

:1234 {
log {
output stdout
}

    route {
            forward_proxy {
                    upstream http://ip_of_squid.local:8080
            }
    }

}

Error: loading initial config: loading new config: loading http app module: provision http: server srv0: setting up route handlers: route 0: loading handler modules: position 0: loading module 'subroute': provision http.handlers.subroute: setting up subroutes: route 0: loading handler modules: position 0: loading module 'forward_proxy': provision http.handlers.forward_proxy: insecure schemes are only allowed to localhost upstreams

Please allow the http:// scheme for arbitrary upstreams, not only localhost. If a downstream client connects via TLS, use the CONNECT method to establish a secure channel with the upsteam HTTP proxy.

This way security is preserved and usability greatly improved. I was so hopeful to find caddy/forwardproxy after trying to use mitmproxy as proxy redirect, but it will always intercept. Then I got insecure schemes are only allowed to localhost upstreams and was stuck again. In a place that, as I understand it, is not necessary. @mholt What do you think?

Dear forwardproxy author, please take a look at this issue

FWIW the "forwardproxy author" is no longer active on this repo, and hasn't been for years; I only aided its development originally (about 10 years ago!) and attempted to upgrade it for v2, but I haven't done any of the actual threat modeling of this.

So I don't know if simply removing the insecure upstreams check is the right thing to do. Alas, I don't have the time to work on this as I have my attention being pulled in mainline Caddy development right now, but if a sufficiently-tiered sponsor needed this worked on, I could prioritize it. I would just have to spend a lot of time getting deeply familiar with the code.

In the meantime, anyone else is welcome to become qualified to decide whether the linked PR is a security risk or not.