Problema de abertura de porta

Acho que há um mal-entendido fundamental aqui. Há uma diferença entre abrir uma porta no firewall e realmente ter um serviço escutando na porta.

Considere o seguinte cenário:

• Estou executando uma instância do Django executada manualmente (ou seja, não iniciada automaticamente) na porta 6900 (porta aleatória que escolhi) localmente.
• Eu executo o NGINX na porta 80 (HTTP) e 443 (HTTPS). Que é o servidor frontend para o backend do Django.

Quando eu inicio o sistema, porque a instância do Django na porta 6900 não foi iniciada, quando você executa netstat -tulpnou ss -tulpn você verá apenas portas de escuta na porta 80 e 443 para NGINX porque a porta 6900 não está vinculada a um serviço ou processo em execução . Portanto, se eu tentar acessar a porta 6900 diretamente de qualquer lugar, recebo um erro "Conexão recusada". Além disso, como o Django não está em execução, quando o NGINX tenta enviar para ele, ele falhará e responderá com "502 Bad Gateway" para quaisquer solicitações.

No entanto, se eu realmente executar a instância do Django, então o Django está vinculado à porta 6900, aparecerá em netstat/ ssoutput e poderá ser acessado pelo exterior, desde que eu tenha a porta 6900 permitida no firewall. E mesmo se eu não tivesse a porta 6900 aberta no firewall, o NGINX seria capaz de passar a solicitação para a porta 6900 localmente e, então, servir o que o Django estiver mostrando.

Pelas descrições da sua configuração, você tem o NGINX em execução (provavelmente em portas padrão) e o firewall está configurado para permitir conexões à porta 4000 e outras portas com uma proxy_passdiretiva para algo em execução na porta 4000 localmente, mas você não tem nenhum programa ou serviço escutando na porta 4000 , portanto, nmapnunca mostrará nada na porta 4000 e a verá como "fechada" porque não há resposta (independentemente de você abri-la no firewall ou não), e o NGINX não encaminhará com respostas 502 Bad Gateway.