sslip.io: domínio com HTTPS para o IP da sua VPS

Olá meus Unicórnios! 🦄✨

Toda vez que eu instalo alguma coisa numa VPS para testar, chega aquele momento chato: o sistema quer um endereço com HTTPS. Não serve o IP puro. O login pelo GitHub pede uma URL de retorno com https://, o webhook de um serviço externo só chama endereço seguro, e o navegador reclama de tudo que não tem cadeado.

No artigo do Chatwoot eu pedi para você criar um subdomínio no painel onde comprou o seu domínio. Funciona, mas e quando você nem tem domínio? Ou quando é só um teste de uma tarde, e você não quer sujar o DNS do domínio de verdade com um teste3-final-agora-vai? 😅

Pois é para isso que existe o sslip.io. Neste artigo eu mostro o que ele é, as formas de escrever o nome, como colocar um certificado do Let's Encrypt de verdade nele com Nginx e Certbot, e os limites que você precisa conhecer antes de confiar nele.

🪄 O que o sslip.io faz

Primeiro, um passo atrás. Quando você digita um endereço no navegador, o computador pergunta a um servidor de DNS: "qual é o IP deste nome?". Normalmente, quem responde é o DNS do domínio que você comprou, com os registros que você cadastrou no painel.

O sslip.io é um servidor de DNS com uma regra só: se o nome tem um IP dentro, a resposta é esse IP. Não há cadastro, não há conta, não há painel. O nome 203.0.113.10.sslip.io não foi criado por ninguém: ele simplesmente responde 203.0.113.10, porque o IP está escrito nele.

Parece bobo, e é exatamente por isso que é genial. Você passa a ter um nome para o IP da sua VPS, e com um nome dá para fazer tudo que um domínio faz: separar sites no Nginx, pedir certificado, cadastrar URL de retorno em login social.

Para conferir, o Windows já traz o nslookup. Abra o PowerShell (clique no menu Iniciar, digite powershell e aperte Enter) e pergunte o IP de um nome. O 1.1.1.1 no fim manda a pergunta para o DNS público da Cloudflare, em vez do DNS do seu provedor de internet:

nslookup 203-0-113-10.sslip.io 1.1.1.1

Não é resposta autoritativa:
Servidor:  one.one.one.one
Address:  1.1.1.1

Nome:    203-0-113-10.sslip.io
Address:  203.0.113.10

O "Não é resposta autoritativa" assusta, mas é normal: quer dizer só que a Cloudflare respondeu em nome do sslip.io, e não o próprio sslip.io. O que importa é a última linha. Repare que 203.0.113.10 nem é um IP de verdade: ele é reservado para exemplos em documentação, e mesmo assim o sslip.io responde, porque ele não confere nada. Ele só lê o nome.

✍️ As formas de escrever o nome

O IP pode entrar no nome de vários jeitos, e todos apontam para o mesmo lugar. No Linux (dentro da VPS, por exemplo), a ferramenta de consulta é o dig. O +noall +answer pede só a linha da resposta, sem o relatório inteiro:

dig +noall +answer 203.0.113.10.sslip.io 203-0-113-10.sslip.io loja.203.0.113.10.sslip.io painel-203-0-113-10.sslip.io cb00710a.sslip.io

203.0.113.10.sslip.io.	3076	IN	A	203.0.113.10
203-0-113-10.sslip.io.	3076	IN	A	203.0.113.10
loja.203.0.113.10.sslip.io. 3076 IN	A	203.0.113.10
painel-203-0-113-10.sslip.io. 3600 IN	A	203.0.113.10
cb00710a.sslip.io.	3076	IN	A	203.0.113.10

Cinco nomes, um IP só. Lendo de cima para baixo:

O prefixo é o que mais uso. Tudo que vem antes do IP é ignorado, então loja., painel. e api. dão três nomes diferentes para a mesma VPS, e o Nginx consegue mandar cada um para um sistema. Foi assim que eu mantive dois sistemas na mesma máquina, cada um com o seu endereço.

O hexadecimal é o IP escrito em base 16, dois dígitos por número: 203 vira cb, 0 vira 00, 113 vira 71 e 10 vira 0a. Não esconde nada de quem sabe converter, mas deixa o endereço menos óbvio num print.

Para IPv6, a regra muda: é sempre com traços, nunca com pontos, e o :: do endereço vira --. Aqui, o registro pedido é o AAAA, que é o "A" do IPv6:

dig +noall +answer AAAA 2001-db8--1.sslip.io

2001-db8--1.sslip.io.	3076	IN	AAAA	2001:db8::1

E o que acontece com um nome sem IP válido dentro? Nada: o sslip.io responde que não tem endereço nenhum. Repare no ANSWER: 0, porque 999 não é um número possível num IP:

dig 999.0.113.10.sslip.io | grep -E "status|ANSWER:"

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13908
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Ah, e funciona até com o IP da sua rede de casa (o do seu notebook no Wi-Fi, por exemplo): o nome resolve do mesmo jeito. Só que aí o HTTPS do Let's Encrypt não tem como chegar, porque ele precisa acessar a máquina pela internet, como você vai ver na próxima seção.

🔐 HTTPS de verdade com Nginx e Certbot

Agora a parte que faz o sslip.io valer ouro. O Let's Encrypt dá certificado de graça, mas antes ele precisa confirmar que você controla o nome. O jeito mais comum é o desafio HTTP: o Certbot coloca um arquivo temporário no seu site, e o Let's Encrypt tenta baixá-lo pela internet, na porta 80, usando o nome pedido. Como o nome do sslip.io aponta para a sua VPS, a visita chega nela, e o certificado sai. Por isso a porta 80 precisa estar aberta para a internet.

Vou montar um site mínimo, só uma página, no nome ola.SEU_IP.sslip.io. Tudo aqui é digitado no terminal da VPS, conectado por SSH como root. Se a sua VPS ainda não tem o Nginx e o Certbot, instale os dois:

apt-get update
apt-get install -y nginx certbot python3-certbot-nginx

O mkdir -p cria a pasta do site, e o nano abre um editor de texto para criar a página dentro dela:

mkdir -p /var/www/ola
nano /var/www/ola/index.html

Cole o conteúdo abaixo. No terminal, o Ctrl+V comum não funciona: cole com Ctrl+Shift+V ou com o botão direito do mouse. Para salvar, aperte Ctrl+O e depois Enter; para sair, Ctrl+X. (O ^ que aparece no rodapé do nano significa "Ctrl".)

<!doctype html>
<html lang="pt-br">
<meta charset="utf-8">
<title>Olá do sslip.io</title>
<body style="font-family:sans-serif;text-align:center;padding-top:15vh">
    <h1>🦄 Olá do sslip.io!</h1>
    <p>Este site não tem domínio comprado: o nome já traz o IP da VPS.</p>
</body>
</html>

Agora o arquivo do Nginx, que diz a ele "quando pedirem este nome, sirva esta pasta":

nano /etc/nginx/sites-available/ola

server {
    listen 80;
    server_name ola.SEU_IP.sslip.io;
    root /var/www/ola;
    index index.html;
}

Troque o SEU_IP pelo IP da sua VPS, com pontos (ola.203.0.113.10.sslip.io, no meu exemplo). A linha mais importante é a server_name: é por ela que o Nginx decide qual site mostrar quando a visita chega, e é ela que o Certbot procura para instalar o certificado.

O Nginx só lê o que está na pasta sites-enabled. O ln -s cria um atalho do arquivo para lá, o nginx -t confere se não tem erro de digitação, e o reload aplica sem derrubar os outros sites que já estejam no ar:

ln -s /etc/nginx/sites-available/ola /etc/nginx/sites-enabled/ola
nginx -t
systemctl reload nginx

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

E agora o certificado. O --nginx manda o Certbot achar sozinho o bloco com esse server_name e editar o arquivo para ligar o HTTPS. O --agree-tos aceita os termos do Let's Encrypt, o --register-unsafely-without-email dispensa cadastrar e-mail (o nome assusta, mas a renovação continua automática) e o -n faz tudo sem perguntas:

certbot --nginx -d ola.SEU_IP.sslip.io --agree-tos --register-unsafely-without-email -n

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for ola.203.0.113.10.sslip.io

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/ola.203.0.113.10.sslip.io/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/ola.203.0.113.10.sslip.io/privkey.pem
This certificate expires on 2026-12-27.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

Deploying certificate
Successfully deployed certificate for ola.203.0.113.10.sslip.io to /etc/nginx/sites-enabled/ola
Congratulations! You have successfully enabled HTTPS on https://ola.203.0.113.10.sslip.io

Pronto. Nenhum domínio comprado, nenhum registro criado em painel nenhum, e o endereço abre com HTTPS no navegador:

Para ver o certificado sem abrir o navegador, o openssl mostra para quem ele foi emitido (subject), quem emitiu (issuer) e a validade:

echo | openssl s_client -connect ola.SEU_IP.sslip.io:443 -servername ola.SEU_IP.sslip.io 2>/dev/null | openssl x509 -noout -subject -issuer -dates

subject=CN = ola.203.0.113.10.sslip.io
issuer=C = US, O = Let's Encrypt, CN = YE2
notBefore=Sep 28 12:22:26 2026 GMT
notAfter=Dec 27 12:22:25 2026 GMT

O certificado vale por 90 dias, e o Certbot deixa uma tarefa agendada que renova sozinha antes de vencer. Para ter certeza de que a renovação vai funcionar, simule uma agora (o --dry-run testa sem trocar nada):

certbot renew --cert-name ola.SEU_IP.sslip.io --dry-run

Simulating renewal of an existing certificate for ola.203.0.113.10.sslip.io

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/ola.203.0.113.10.sslip.io/fullchain.pem (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

🚨 O erro que aparece antes de tudo ficar pronto

Se você só for ler um pedaço deste artigo, leia este. 🙏 Na minha VPS já rodavam outros sistemas com HTTPS. Antes de criar o arquivo do Nginx, eu testei o endereço novo, só por curiosidade:

curl -sS https://ola.SEU_IP.sslip.io/

curl: (60) SSL: no alternative certificate subject name matches target host name 'ola.203.0.113.10.sslip.io'
More details here: https://curl.se/docs/sslcerts.html

O nome já chegava na VPS (o sslip.io não espera configuração nenhuma), mas o Nginx não tinha bloco para ele. Então ele atendeu com o site padrão da porta 443, que era outro sistema, com o certificado de outro nome. O curl recusa, e o navegador mostra a tela vermelha de "sua conexão não é particular".

E agora a pegadinha que me pegou de verdade: o nome com pontos e o nome com traços são nomes diferentes. Os dois apontam para o mesmo IP, mas o certificado foi emitido para um só. Com tudo funcionando no ola.203.0.113.10.sslip.io, eu testei a versão com traços:

curl -sS https://ola-SEU_IP_COM_TRACOS.sslip.io/

curl: (60) SSL: no alternative certificate subject name matches target host name 'ola-203-0-113-10.sslip.io'

Mesmo erro, mesmo motivo. Então a regra é: escolha uma forma e use sempre a mesma, no server_name, no Certbot, no .env do sistema e na URL de retorno cadastrada no GitHub ou no Google. Se aparecer esse erro com o nome certo, confira letra por letra se o server_name é idêntico ao que você digitou.

⚖️ Os limites que você precisa conhecer

O sslip.io é maravilhoso para teste, mas não é mágica (tá, é um pouquinho). Quatro coisas mudam a decisão de usá-lo ou não:

1. Não existe certificado curinga. Um certificado *.203.0.113.10.sslip.io, que valeria para todos os prefixos de uma vez, exige o desafio por DNS: você cria um registro TXT no domínio para provar que é o dono. Só que o DNS do sslip.io não é seu, então não tem onde criar esse registro. O próprio serviço avisa que não suporta curinga. A saída é pedir um certificado para cada nome, como fiz acima.

2. O limite do Let's Encrypt é dividido com o mundo inteiro. O Let's Encrypt limita quantos certificados um mesmo domínio registrado recebe por semana. Para ele, todos os nomes *.sslip.io são do mesmo domínio, e eu conferi que o sslip.io não está na Public Suffix List (a lista que faria cada IP contar como um domínio separado). A página do serviço conta que o Let's Encrypt já subiu esse limite de 50 para 250 mil certificados, mas ele é compartilhado por todos os usuários. Se o seu pedido for recusado por limite, o próprio sslip.io sugere trocar para o nip.io, mantido pelas mesmas pessoas e com as mesmas regras:

dig +noall +answer loja.203.0.113.10.nip.io 203-0-113-10.nip.io

loja.203.0.113.10.nip.io. 3600	IN	A	203.0.113.10
203-0-113-10.nip.io.	3600	IN	A	203.0.113.10

3. O nome depende de um serviço que não é seu. Se o sslip.io sair do ar, o seu endereço para de resolver, e você não tem para quem reclamar. E se você trocar de VPS, o IP muda, o nome muda junto, e aí é refazer o server_name, o certificado e todas as URLs cadastradas nos sistemas.

4. O nome é público, e o IP está nele. Todo certificado do Let's Encrypt é publicado em registros abertos de transparência (o Certificate Transparency), e qualquer um pode consultar os nomes emitidos. Como o IP está escrito no nome, quem vê o endereço sabe exatamente onde fica a sua VPS. Para um teste isso não muda nada; para um painel administrativo, pense duas vezes e deixe uma senha forte na frente.

Por isso eu uso o sslip.io para o que ele faz de melhor: teste de instalação, demonstração para cliente, sistema interno que precisa de HTTPS só porque o login social exige. O site de verdade, que vai para o cartão de visita, merece um domínio seu.

🧹 Desfazendo o teste

Terminou o teste? Deixar site esquecido na VPS é pedir para ter surpresa depois. Para apagar tudo que foi criado aqui: o certbot delete remove o certificado (e para de renová-lo), o rm apaga o arquivo do Nginx, o atalho e a pasta do site, e o reload aplica:

certbot delete --cert-name ola.SEU_IP.sslip.io -n
rm /etc/nginx/sites-enabled/ola /etc/nginx/sites-available/ola
rm -r /var/www/ola
nginx -t
systemctl reload nginx

Repare que não tem nada para apagar do lado do sslip.io: o nome nunca foi "criado", então ele continua respondendo o seu IP para sempre, só que agora sem site nenhum atrás. 🪄

Por hoje é só, meus unicórnios! 🦄✨

Que a magia do arco-íris continue brilhando em suas vidas! Até mais! 🌈🌟