~/ / Artigos sobre IA / LLMs locais em uma VPS / nginx na frente do Ollama: autenticação básica, HTTPS e configurações para streaming

nginx na frente do Ollama: autenticação básica, HTTPS e configurações para streaming

Por padrão, o Ollama escuta no próprio servidor, que é o lugar mais seguro para ele. Quando outra máquina precisa acessá-lo, o FAQ do Ollama indica um servidor proxy como o nginx. Este artigo monta essa configuração a partir da documentação do nginx: uma senha, HTTPS, as configurações que importam para respostas transmitidas em fluxo e um firewall que fecha as outras portas.

Publicado: 2026-10-26 · 6 min de leitura · Verificado na documentação oficial do Ollama e do nginx em 2026-10-26. Os valores padrão das diretivas dependem da versão do nginx, por isso confira a versão que você usa.

O que diz o FAQ do Ollama

O FAQ do Ollama diz que o Ollama executa um servidor HTTP e pode ser exposto por meio de um servidor proxy como o Nginx. O exemplo dele escuta na porta 80, define um server_name, encaminha as requisições com proxy_pass http://localhost:11434 e define o cabeçalho Host como localhost:11434.

A página do FAQ que verificamos não descreve nenhuma autenticação para o servidor do Ollama. Por isso a senha precisa vir do proxy que fica na frente dele. O Ollama escuta em 127.0.0.1, porta 11434, por padrão, de modo que um nginx no mesmo servidor consegue alcançá-lo sem alterar esse endereço.

Uma senha com autenticação básica

O ngx_http_auth_basic_module limita o acesso verificando um nome de usuário e uma senha. Duas diretivas fazem o trabalho: auth_basic, cuja string é usada como realm e que por padrão é off, e auth_basic_user_file, que indica o arquivo de senhas.

Diretiva	Padrão	O que diz a documentação
auth_basic string \| off;	off	O parâmetro é usado como o realm de autenticação. O valor off cancela uma configuração herdada de um nível anterior.
auth_basic_user_file file;	nenhum	O arquivo tem uma entrada name:password por linha, e as linhas que começam com # são comentários.

Tipos de senha aceitos: senhas criptografadas com crypt() e hashes apr1, ambos gerados com o utilitário htpasswd do Apache ou com openssl passwd.
A sintaxe {SCHEME}data também é aceita. A página diz que PLAIN é apenas um exemplo e não deve ser usado, e que SHA, um SHA-1 sem salt, também não deve ser usado, porque é vulnerável a ataques com rainbow tables. SSHA é um SHA-1 com salt.
O exemplo da documentação: location / { auth_basic "closed site"; auth_basic_user_file conf/htpasswd; }

A página cita htpasswd e openssl passwd, mas não dá comandos. As formas de uso comum, que são nossas e não da página, são htpasswd -c /etc/nginx/ollama.htpasswd alice, que pede uma senha, e openssl passwd -apr1, que imprime um hash para colar depois do nome de usuário e de dois-pontos.

HTTPS e certificado

Nossa leitura, não uma afirmação dos documentos: a autenticação básica envia a senha a cada requisição, então use-a somente atrás de HTTPS. Segundo a documentação do nginx, um servidor precisa do parâmetro ssl no socket de escuta e dos locais do certificado e da chave privada.

Diretiva	Exemplo da documentação
listen	listen 443 ssl;
server_name	server_name www.example.com;
ssl_certificate	ssl_certificate www.example.com.crt;
ssl_certificate_key	ssl_certificate_key www.example.com.key;

Por padrão, o nginx usa ssl_protocols TLSv1.2 TLSv1.3 e ssl_ciphers HIGH:!aNULL:!MD5, portanto configurá-los explicitamente geralmente não é necessário.
A chave privada deve ficar em um arquivo com acesso restrito, mas precisa ser legível pelo processo mestre do nginx.
Se os navegadores relatarem erros para um certificado de uma autoridade conhecida, talvez o servidor precise enviar os certificados intermediários. O certificado do servidor deve aparecer antes dos certificados encadeados no arquivo combinado, caso contrário o nginx não inicia e exibe um erro de key values mismatch.
A página de primeiros passos do Let's Encrypt diz que, se o seu provedor não obtém certificados para você e você pode administrar o seu servidor, é possível executar um cliente ACME, e que ela recomenda o Certbot para a maioria das pessoas.

Configurações para respostas em fluxo e lentas

Um modelo escreve a resposta aos poucos, e o primeiro trecho pode demorar a chegar, por exemplo enquanto um modelo grande é carregado na memória. Três configurações do nginx determinam como isso aparece para quem está do lado de fora.

Diretiva	Padrão	O que diz a documentação
proxy_buffering	on	Quando o buffering está desativado, a resposta é repassada ao cliente de forma síncrona, assim que é recebida. Quando está ativado, o nginx primeiro guarda a resposta em buffers.
proxy_read_timeout	60s	O timeout é definido apenas entre duas operações de leitura sucessivas, não para a resposta inteira. Se o servidor proxy não transmitir nada dentro desse tempo, a conexão é encerrada.
proxy_http_version	1.1 desde o nginx 1.29.7	Antes da 1.29.7, o padrão era 1.0. A versão 1.1 ou 2 é recomendada para conexões keepalive.

Nossa leitura, não uma afirmação dos documentos: para ver a resposta aparecer enquanto é escrita, desative proxy_buffering na location do Ollama e, se o modelo puder ficar em silêncio por mais de um minuto enquanto é carregado, aumente proxy_read_timeout. Definir proxy_http_version 1.1 explicitamente é inofensivo em qualquer versão.

Juntando tudo

Esta configuração combina as diretivas acima para um único nome de servidor. É uma composição nossa a partir das diretivas documentadas, então teste-a com nginx -t antes de recarregar.

Linha	Por quê
server {	um bloco server para o nome do Ollama
listen 443 ssl;	HTTPS
server_name ollama.example.com;	o seu próprio nome
ssl_certificate /etc/ssl/ollama.crt;	o certificado, com os intermediários depois dele
ssl_certificate_key /etc/ssl/ollama.key;	a chave privada, legível apenas conforme o necessário
auth_basic "ollama";	ativa a senha
auth_basic_user_file /etc/nginx/ollama.htpasswd;	onde os usuários ficam guardados
location / {	tudo vai para o Ollama
proxy_pass http://localhost:11434;	do FAQ do Ollama
proxy_set_header Host localhost:11434;	do FAQ do Ollama
proxy_http_version 1.1;	recomendado para keepalive
proxy_buffering off;	para que a resposta chegue em fluxo
proxy_read_timeout 300s;	permite um primeiro trecho lento
}	fim da location
}	fim do server

Feche as outras portas

O proxy só ajuda se as pessoas não conseguirem chegar ao Ollama, nem ao aplicativo por trás dele, por outro caminho. O Ollama permanece no endereço padrão, e um firewall admite apenas os endereços que você usa.

Tarefa	Comando da documentação do Ubuntu
Ligar o firewall	sudo ufw enable
Permitir uma porta	sudo ufw allow 22
Permitir um endereço para uma porta	sudo ufw allow proto tcp from 192.168.0.2 to any port 22
Permitir uma sub-rede inteira	troque o endereço por 192.168.0.0/24
Verificar o estado	sudo ufw status

A página do Ubuntu diz que o UFW está inicialmente desativado. Ela não traz nenhum aviso sobre ficar bloqueado fora do servidor por SSH. Nossa recomendação: libere a porta do seu SSH antes de ativar o firewall em um servidor que você acessa remotamente, e libere a porta 443 apenas para os endereços que precisam dela.