Я использую обратный прокси-сервер lighttpd для обслуживания django с помощью gunicorn. Теперь этот конфиг работал:
proxy.server = ("" => ( "" => (
"host" => "127.0.0.1",
"port" => 8000,
)))
Теперь я переместил пулемет в контейнер и использовал:
proxy.server = ("" => ( "" => (
"host" => "192.168.1.2",
"port" => 8000,
)))
Теперь у каждого запроса есть ip 192.168.1.1 глазами пулеметчика. Я бы понял, если обратный прокси запутывает реальный IP, но почему тогда он работал с localhost?
для обоих я получаю
X-Forwarded-For: client-ip
X-Host: the.domain
X-Forwarded-Proto: http
где client-ip - это общедоступное пространство IP.
запросы исходят от
хост:
nc: connect to 127.0.0.1 8000 from localhost (127.0.0.1) 44953 [44953]
контейнер:
nc: connect to 192.168.1.2 8000 from host (192.168.1.1) 60027 [60027]
у самого контейнера есть ip 192.168.1.2, хост-мост имеет 192.168.1.1 а маршруты внутри контейнера:
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2
у хозяина есть:
192.168.1.0/24 dev bridge proto kernel scope link src 192.168.1.1
РЕДАКТИРОВАТЬ: X-Forwarded-For был одинаковым для обоих запросов. (Проверено с nc -vlp 8000).
Моя ставка? lighttpd добавляет X-Forwarded-For заголовок, а в Django есть что-то жестко запрограммированное, чтобы знать, 127.0.0.1 вряд ли будет настоящим удаленным IP-адресом, если этот заголовок присутствует.
Вы должны убедиться, что X-Forwarded-For присутствует заголовок, затем заставьте Django использовать его в качестве удаленного адреса (похоже, способ сделать это Вот).