Closed r06ertray closed 3 months ago
Ideally, we need to be able to reproduce the bug in the most minimal way possible. This allows us to write regression tests to verify the fix is working. If we can't reproduce it, then you'll have to test our changes for us until it's fixed -- and then we can't add test cases, either.
I've attached a template below that will help make this easier and faster! This will require some effort on your part -- please understand that we will be dedicating time to fix the bug you are reporting if you can just help us understand it and reproduce it easily.
This template will ask for some information you've already provided; that's OK, just fill it out the best you can. :+1: I've also included some helpful tips below the template. Feel free to let me know if you have any questions!
Thank you again for your report, we look forward to resolving it!
## 1. Environment
### 1a. Operating system and version
```
paste here
```
### 1b. Caddy version (run `caddy version` or paste commit SHA)
```
paste here
```
### 1c. Go version (if building Caddy from source; run `go version`)
```
paste here
```
## 2. Description
### 2a. What happens (briefly explain what is wrong)
### 2b. Why it's a bug (if it's not obvious)
### 2c. Log output
```
paste terminal output or logs here
```
### 2d. Workaround(s)
### 2e. Relevant links
## 3. Tutorial (minimal steps to reproduce the bug)
Environment: Please fill out your OS and Caddy versions, even if you don't think they are relevant. (They are always relevant.) If you built Caddy from source, provide the commit SHA and specify your exact Go version.
Description: Describe at a high level what the bug is. What happens? Why is it a bug? Not all bugs are obvious, so convince readers that it's actually a bug.
Tutorial: What are the minimum required specific steps someone needs to take in order to experience the same bug? Your goal here is to make sure that anyone else can have the same experience with the bug as you do. You are writing a tutorial, so make sure to carry it out yourself before posting it. Please:
curl
.Example of a tutorial:
Create a config file: ``` { ... } ``` Open terminal and run Caddy: ``` $ caddy ... ``` Make an HTTP request: ``` $ curl ... ``` Notice that the result is ___ but it should be ___.
Debian GNU/Linux 10 (buster), x86_64
caddy version
or paste commit SHA)v2.8.4 h1:q3pe0wpBj1OcHFZ3n/1nl4V4bxBrYoSoab7rL9BMYNk=
When we enable proxy_protocol in Caddy 2.8.4, the _remoteip and _clientip in the request still show as 127.0.0.1, which is not as expected.
{......"request":{"remote_ip":"127.0.0.1","remote_port":"38704","client_ip":"127.0.0.1"}......}
While In caddy 2.7.6:
{......"request":{"remote_ip":"146.56.*.*","remote_port":"0","client_ip":"146.56.*.*"}......}
1、Caddyfile as below,
{
servers :81 {
protocols h1 h2c
listener_wrappers {
proxy_protocol
}
}
}
:81 {
log {
output file /var/log/caddy/info.log
}
file_server browse
root * /opt/website
}
my.domain.com {
reverse_proxy /* 127.0.0.1:81 {
transport http {
proxy_protocol v2
}
}
}
2、Restart caddy service
systemctl restart caddy
caddy.service
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile --force
3、On another host, Use curl to make an HTTP request
curl https://my.domain.com
4、tail /var/log/caddy/info.log
{......"request":{"remote_ip":"127.0.0.1","remote_port":"38704","client_ip":"127.0.0.1"}......}
Ah, I see it. You'll need to add the trusted IP address ranges in allow
inside the proxy_protocol
configuration. In other words, the global options in your config would be like this:
{
servers :81 {
protocols h1 h2c
listener_wrappers {
proxy_protocol {
allow xxx.xxx.xxx.xx/xx
}
}
}
}
Trusting the proxy headers from any source is not secure, so the default is to ignore the source address stated in the header. We switched the backing library that processes the proxy_protocol stream, and I didn't realize the earlier library accepted any source by default. Sorry for the breaking change 😅 I also realize now there are additional configuration options (i.e. deny
, fallback_policy
) that were not added to the documentation, though they don't affect your use case much. You can use fallback_policy
to override the ignore
behavior.
Though I'm closing the issue as working-as-intended, feel free to continue the discussion.
Please forgive my poor expression.
I need to use Caddy as a backend(:81) for reverse proxy and then use proxy_protocol to obtain the client IP passed from the frontend.
In Caddy 2.7.6, the :81 in the previously provided Caddyfile could normally obtain the client IP, but after Caddy 2.8.0, the obtained client IP becomes 127.0.0.1 (as if proxy_protocol was not configured).
The my.domain.com in the configuration is just an example of the frontend for the reverse proxy.
Have you tried my suggestion from above?
I got it, the IP address ranges in allow are used to restrict the frontend, not the client.
In this case, allow 127.0.0.1/32 is sufficient.
Thank you!
The Caddyfile is as follows:
Starting from Caddy version 2.8.0, the _remoteip and _clientip of request in the log file are displayed as 127.0.0.1