# Servico Interno Tailscale

> Expõe um serviço que roda em casa ou no escritório com domínio e HTTPS válido, acessível só pela VPN privada, sem abrir porta no roteador. Use ao publicar dashboard, API ou app interno que não deve ficar na internet pública.

- Skill: `slayer1dev/servico-interno-tailscale` (Agent Skill)
- Install (CLI): `npx skillmds@latest add slayer1dev/servico-interno-tailscale`
- Raw SKILL.md: https://api.skillmd.com/api/skills/slayer1dev/servico-interno-tailscale/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: Slayer1Dev (https://skillmd.com/u/slayer1dev)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/slayer1dev/servico-interno-tailscale

---


# Serviço interno com domínio e HTTPS

Para quando existe algo rodando numa máquina sua e você quer acessar de qualquer lugar — com domínio de verdade e cadeado no navegador — **sem** expor na internet.

A tentação é abrir porta no roteador e apontar um DNS. Isso coloca o serviço no alcance de qualquer varredura automatizada, e daí em diante você depende da autenticação da aplicação ser perfeita. Melhor não estar alcançável.

## O que resolve isso

Uma VPN mesh (Tailscale, por exemplo) já dá a cada máquina um nome e um IP estáveis. Com o proxy embutido, você ganha HTTPS com certificado publicamente válido em um domínio que **só resolve dentro da sua rede**.

```
https://maquina.sua-rede.ts.net:8443  →  http://127.0.0.1:3051
```

Ninguém fora da VPN alcança. Não há porta aberta. O certificado é real, então o navegador não reclama.

## Passos

**1. Confirme que o DNS da VPN está ligado.** O nome precisa resolver:

```bash
getent hosts maquina.sua-rede.ts.net
```

Sem isso, você só tem o IP — funciona, mas sem HTTPS válido.

**2. Suba o serviço em `127.0.0.1`, não em `0.0.0.0`.**

Este é o ponto que a maioria erra. Bind em `0.0.0.0` expõe na rede local inteira — Wi-Fi de visita, TV, qualquer coisa comprometida no mesmo roteador. O proxy da VPN alcança `127.0.0.1` normalmente; não há motivo para abrir mais.

**3. Configure o proxy:**

```bash
tailscale serve --bg --https=8443 http://127.0.0.1:3051
tailscale serve status
```

Portas HTTPS costumam ser limitadas a um conjunto fixo (443, 8443, 10000). Use uma por serviço.

**4. Verifique do cliente, não do host:**

```bash
curl -o /dev/null -w "%{http_code}\n" https://maquina.sua-rede.ts.net:8443/
```

Sem `-k`. Com `-k` você prova que existe TLS, não que o certificado é confiável.

## Armadilhas

- **Frameworks de frontend recusam host desconhecido.** Vite e similares checam o `Host` e respondem "Blocked request". Adicione o domínio em `allowedHosts` antes de testar, senão você depura o proxy à toa.

- **VPN em container precisa enxergar o host.** Se o cliente da VPN roda em container, ele precisa de modo `host` na rede — senão `127.0.0.1` é o container, não a máquina.

- **O serviço precisa sobreviver a reboot.** Coloque em `systemd` com `enable`, e habilite `linger` se for serviço de usuário, senão ele morre no logout.

- **Duas portas, dois serviços, um domínio.** Frontend e API no mesmo host: sirva o frontend e deixe ele fazer proxy de `/api`. Um origin só evita CORS e simplifica o cookie.

## Quando NÃO usar

- Se o serviço precisa ser público (site, landing page, webhook de terceiro). Webhook de marketplace ou gateway de pagamento **não** alcança endereço de VPN.
- Se pessoas de fora precisam acessar sem instalar a VPN.

Nesses casos é hospedagem pública com autenticação de verdade — e aí a proteção passa a ser a aplicação, não a rede.