Reverse Proxy JSON Config

[harrisreynolds]

I am making progress with Caddy. This is a very interesting project.

I have this Caddyfile:

www.simplsites.com www.simplpages.com {
reverse_proxy * {
to 172.17.0.5:5000
header_up X-Real-IP {remote_host}
header_up X-Forwarded-Proto {scheme}
header_up Access-Control-Allow-Headers Cache-Control,Content-Type
transport http {
read_buffer 8192
}
}
}

That I need to port to JSON but very hard to see where some things go for the “reverse_proxy” section. I will update Wiki with more examples to help future people if I can get some help.

Questions:

1. Where does the “to” go? This is obviously the most important question.
2. Is it important to include the “*” so all traffic goes to backend server?
3. Is the “read_buffer” important for a reverse proxy?

1. Caddy version (caddy version):

v2.0.0 h1:pQSaIJGFluFvu8KDGDODV8u4/QRED/OPyIR+MWYYse8=

2. How I run Caddy:

caddy run

a. System environment:

Ubuntu 16

b. Command:

N/A

c. Service/unit/compose file:

N/A

d. My complete Caddyfile or JSON config:

www.simplsites.com www.simplpages.com {
reverse_proxy * {
to 172.17.0.5:5000
header_up X-Real-IP {remote_host}
header_up X-Forwarded-Proto {scheme}
header_up Access-Control-Allow-Headers Cache-Control,Content-Type
transport http {
read_buffer 8192
}
}
}

3. The problem I’m having:

I need to use JSON/API for configuring managing Caddy. Porting the reverse_proxy section of the above Caddy file to JSON is very difficult.

4. Error messages and/or full log output:

N/A

5. What I already tried:

This is my JSON file currently:

{
“admin”: {
“disabled”: false
},

“apps”: {
“http”: {
“servers”: {
“webase”: {
“listen”: [
“:443”
],
“routes”: [
{
“match”: [
{
“host”: [
“*.webase.com”, “www.simplsites.com”, “www.simplpages.com”
]
}
],
“handle”: [
{
“handler”: “reverse_proxy”,
“transport”: {
“protocol”: “http”
},

              // is it important to include the "*" so all traffic goes to backend server?
              // where does the "to" go?
              // is the "read_buffer" important?
            }
          ]
        }
      ]
    }
  }
}

}
}

6. Links to relevant resources:

N/A

[francislavoie]

Please put ``` on the lines before and after your config when posting it in the forums to use code block formatting, it’ll preserve whitespace. It’s very hard to read it otherwise.

I think you’re looking for the caddy adapt command – it will take a Caddyfile as input, and give you the adapted JSON as output. You can use this to quickly get a valid JSON config you can use as a basis.

Regarding your specific questions:

@harrisreynolds

1. Where does the “to” go? This is obviously the most important question.

In Caddyfile, the shorter way to write it is like this:

reverse_proxy 172.17.0.5:5000 {
	...
}

to not really necessary because in the Caddyfile, you have the convenience of putting it on the same line.

In the JSON, the equivalent is upstreams → dial:

JSON Config Structure - Caddy Documentation

@harrisreynolds

2. Is it important to include the “*” so all traffic goes to backend server?

No, the default matcher is *, as explained here in the matcher docs. You can omit it if your next non-matcher argument does not start with /, which would otherwise be parsed as a path matcher.

Request matchers (Caddyfile) - Caddy Documentation

In the JSON, if you omit a matcher, it’s the same as meaning “match all requests”.

@harrisreynolds

3. Is the “read_buffer” important for a reverse proxy?

Probably not. It’ll work just fine without it. Consider it just an option for performance tuning, if you need it. Typically, you should use the defaults unless you have a good reason not to.

@harrisreynolds

header_up X-Forwarded-Proto {scheme}

FYI you can omit this line, Caddy will do this for you automatically.

@harrisreynolds

“admin”: {
“disabled”: false
},

FYI, disabling the admin endpoint will make it impossible to gracefully reload the Caddy config. I’d strongly recommend leaving it enabled unless you have a good reason to turn it off. You also won’t be able to use the API if you turn it off.

[harrisreynolds]

Thanks for the reply… that adapt command is exactly what I need… one clarification:

"admin": {
"disabled": false
}

If disabled is set to false that would mean it was enabled correct? I definitely want to be able to administer the server via the API.

[matt (Matt Holt)]

Disabled = false is the default, so you can omit it. It is enabled by default.

[francislavoie]

Right - sorry for the confusion. Boolean logic sometimes…