Eu uso um proxy reverso lighttpd para servir django com gunicorn. Agora esta configuração funcionou:
proxy.server = ("" => ( "" => (
"host" => "127.0.0.1",
"port" => 8000,
)))
Agora eu movi o gunicorn para um container e uso:
proxy.server = ("" => ( "" => (
"host" => "192.168.1.2",
"port" => 8000,
)))
Agora, toda solicitação tem o ip 192.168.1.1 visto por gunicorn. Eu entenderia, se o proxy reverso ofusca o IP real, mas por que ele funcionava com o localhost então?
para ambos eu recebo
X-Forwarded-For: client-ip
X-Host: the.domain
X-Forwarded-Proto: http
onde o client-ip é um espaço ip público.
os pedidos vêm de
host:
nc: connect to 127.0.0.1 8000 from localhost (127.0.0.1) 44953 [44953]
contêiner:
nc: connect to 192.168.1.2 8000 from host (192.168.1.1) 60027 [60027]
o container em si tem ip 192.168.1.2 , o host-bridge tem 192.168.1.1 e as rotas dentro do container são:
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2
o host possui:
192.168.1.0/24 dev bridge proto kernel scope link src 192.168.1.1
EDITAR:
O X-Forwarded-For foi o mesmo para ambos os pedidos. (Testado com nc -vlp 8000 ).
Minha aposta? O lighttpd está adicionando um X-Forwarded-For header, e o Django tem algo hardcode em algum lugar para saber que 127.0.0.1 provavelmente não será o verdadeiro endereço IP remoto se esse cabeçalho estiver presente.
Você deve verificar se o cabeçalho X-Forwarded-For está presente e, em seguida, obter o Django para usá-lo como o endereço remoto (parece que a maneira de fazer isso é aqui ).