{"id":1789,"date":"2026-10-05T13:55:09","date_gmt":"2026-10-05T16:55:09","guid":{"rendered":"https:\/\/www.linuxpro.com.br\/?p=1789"},"modified":"2026-10-05T13:55:09","modified_gmt":"2026-10-05T16:55:09","slug":"caddy-no-linux-servidor-web-com-https-automatico","status":"publish","type":"post","link":"https:\/\/www.linuxpro.com.br\/en\/2026\/10\/caddy-no-linux-servidor-web-com-https-automatico\/","title":{"rendered":"Caddy on Linux: web server with automatic HTTPS"},"content":{"rendered":"<p><img loading=\"lazy\" decoding=\"async\" alt=\"Mascote do LinuxPro encaixando um cadeado verde de HTTPS no port\u00e3o com o logo do Caddy, por onde o tr\u00e1fego da internet passa at\u00e9 os racks de servidores, com o cachorro caramelo sentado ao lado\" src=\"\/wp-content\/uploads\/2026\/10\/caddy-servidor-web-https-automatico.webp\" width=\"1486\" height=\"856\" \/><\/p>\n<p>Colocar um site no ar com HTTPS costumava ser uma receita de tr\u00eas ingredientes: um servidor web, o certbot e um cron para renovar o certificado \u2014 e um nginx.conf de cinquenta linhas para amarrar tudo. O <a href=\"https:\/\/caddyserver.com\/\">Caddy<\/a> resolve isso numa pe\u00e7a s\u00f3: voc\u00ea escreve o nome do dom\u00ednio no arquivo de configura\u00e7\u00e3o e ele emite o certificado, renova sozinho e redireciona HTTP para HTTPS. Este guia instala o Caddy no Ubuntu e no Debian pelo reposit\u00f3rio oficial, configura site est\u00e1tico, proxy reverso com balanceamento e PHP, e mostra onde ficam os certificados, os logs e a API de administra\u00e7\u00e3o.<\/p>\n<h2>O que \u00e9 o Caddy<\/h2>\n<p>O Caddy \u00e9 um servidor web e proxy reverso escrito em <a href=\"\/2026\/09\/a-historia-da-linguagem-go\/\">Go<\/a>, distribu\u00eddo como um bin\u00e1rio \u00fanico e licenciado sob Apache 2.0. Matt Holt come\u00e7ou a escrev\u00ea-lo em 2014, ainda na faculdade; a primeira vers\u00e3o p\u00fablica (0.5.0) saiu em abril de 2015, e a linha 2.x, reescrita do zero, chegou em maio de 2020. A vers\u00e3o est\u00e1vel atual \u00e9 a <a href=\"https:\/\/github.com\/caddyserver\/caddy\/releases\/tag\/v2.11.7\">2.11.7<\/a>, de 3 de outubro de 2026.<\/p>\n<p>Tr\u00eas caracter\u00edsticas o separam do nginx e do Apache:<\/p>\n<ul>\n<li><strong>HTTPS autom\u00e1tico e por padr\u00e3o.<\/strong> Todo site com nome de dom\u00ednio p\u00fablico ganha certificado de uma CA ACME (Let&#8217;s Encrypt ou ZeroSSL) e renova\u00e7\u00e3o autom\u00e1tica. Nomes locais, como <code>localhost<\/code>, recebem certificados de uma CA interna do pr\u00f3prio Caddy.<\/li>\n<li><strong>Protocolos modernos ligados de f\u00e1brica.<\/strong> HTTP\/2 e, desde a 2.6 (setembro de 2022), HTTP\/3. A 2.10, de abril de 2025, acrescentou troca de chaves p\u00f3s-qu\u00e2ntica (<code>x25519mlkem768<\/code>) por padr\u00e3o e suporte a Encrypted ClientHello (ECH).<\/li>\n<li><strong>Configura\u00e7\u00e3o por API.<\/strong> O formato nativo \u00e9 JSON, carregado e alterado ao vivo por uma API REST em <code>localhost:2019<\/code>. O Caddyfile, que usaremos aqui, \u00e9 um adaptador mais leg\u00edvel que vira esse JSON.<\/li>\n<\/ul>\n<p>O que ele n\u00e3o faz: n\u00e3o tem o ecossistema de m\u00f3dulos din\u00e2micos do nginx nem o <code>.htaccess<\/code> do Apache. Plugins entram compilados no bin\u00e1rio \u2014 veremos como no fim.<\/p>\n<figure><img loading=\"lazy\" decoding=\"async\" src=\"\/wp-content\/uploads\/2026\/10\/caddy-arquitetura-https.webp\" alt=\"Diagrama: clientes acessam o Caddy nas portas 443 e 80 de um servidor Ubuntu ou Debian; o Caddy obt\u00e9m certificados de uma CA ACME, guarda-os em \/var\/lib\/caddy, l\u00ea o \/etc\/caddy\/Caddyfile e encaminha para site est\u00e1tico, aplica\u00e7\u00f5es em loopback e PHP-FPM; a API de administra\u00e7\u00e3o fica em localhost:2019\" width=\"1200\" height=\"640\" \/><figcaption>O Caddy fica na frente de tudo: s\u00f3 as portas 80 e 443 ficam abertas, e os aplicativos escutam apenas no loopback.<\/figcaption><\/figure>\n<h2>Instalando pelo reposit\u00f3rio oficial<\/h2>\n<p>O projeto mant\u00e9m pacotes para Debian, Ubuntu e Raspberry Pi OS num reposit\u00f3rio hospedado no Cloudsmith. Os comandos abaixo s\u00e3o os da <a href=\"https:\/\/caddyserver.com\/docs\/install#debian-ubuntu-raspbian\">documenta\u00e7\u00e3o oficial<\/a>; testei-os num Debian 13 limpo e o pacote instalou a 2.11.7:<\/p>\n<pre><code class=\"language-bash\">sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl\ncurl -1sLf 'https:\/\/dl.cloudsmith.io\/public\/caddy\/stable\/gpg.key' \\\n  | sudo gpg --dearmor -o \/usr\/share\/keyrings\/caddy-stable-archive-keyring.gpg\ncurl -1sLf 'https:\/\/dl.cloudsmith.io\/public\/caddy\/stable\/debian.deb.txt' \\\n  | sudo tee \/etc\/apt\/sources.list.d\/caddy-stable.list\nsudo chmod o+r \/usr\/share\/keyrings\/caddy-stable-archive-keyring.gpg\nsudo chmod o+r \/etc\/apt\/sources.list.d\/caddy-stable.list\nsudo apt update\nsudo apt install caddy<\/code><\/pre>\n<p>Se o sistema n\u00e3o tiver o <code>gpg<\/code>, instale antes com <code>sudo apt install -y gpg<\/code>. O pacote faz bastante coisa sozinho:<\/p>\n<ul>\n<li>cria o usu\u00e1rio de sistema <code>caddy<\/code>, com <code>$HOME<\/code> em <code>\/var\/lib\/caddy<\/code> e membro do grupo <code>www-data<\/code>;<\/li>\n<li>instala e j\u00e1 inicia o servi\u00e7o <code>caddy.service<\/code>, que l\u00ea <code>\/etc\/caddy\/Caddyfile<\/code>;<\/li>\n<li>instala tamb\u00e9m o <code>caddy-api.service<\/code>, desativado, para quem prefere configurar s\u00f3 pela API;<\/li>\n<li>deixa um Caddyfile de exemplo servindo <code>\/usr\/share\/caddy<\/code> na porta 80.<\/li>\n<\/ul>\n<pre><code class=\"language-bash\">caddy version\nsystemctl status caddy --no-pager\ncurl -I http:\/\/localhost<\/code><\/pre>\n<p>Libere as portas no firewall. O HTTP\/3 roda sobre UDP, ent\u00e3o a 443 precisa estar aberta nos dois protocolos:<\/p>\n<pre><code class=\"language-bash\">sudo ufw allow 80\/tcp\nsudo ufw allow 443\/tcp\nsudo ufw allow 443\/udp<\/code><\/pre>\n<h2>Primeiro site com HTTPS autom\u00e1tico<\/h2>\n<p>Antes de mexer no Caddyfile, confira os pr\u00e9-requisitos do certificado p\u00fablico: o registro A\/AAAA do dom\u00ednio apontando para o servidor e as portas 80 e 443 acess\u00edveis pela internet. Sem isso a CA n\u00e3o consegue validar o dom\u00ednio \u2014 e, se voc\u00ea errar muitas vezes, bate no limite de requisi\u00e7\u00f5es dela.<\/p>\n<p>Substitua o conte\u00fado de <code>\/etc\/caddy\/Caddyfile<\/code>:<\/p>\n<pre><code class=\"language-text\">{\n\temail admin@exemplo.com.br\n}\n\nwww.exemplo.com.br {\n\troot * \/var\/www\/exemplo\n\tfile_server\n\tencode zstd gzip\n}\n\nexemplo.com.br {\n\tredir https:\/\/www.exemplo.com.br{uri} permanent\n}<\/code><\/pre>\n<p>O bloco sem nome no topo guarda as op\u00e7\u00f5es globais; o e-mail identifica a conta ACME junto \u00e0 CA, que pode us\u00e1-lo para avisos sobre a conta. Cada bloco seguinte \u00e9 um site, identificado pelo endere\u00e7o. N\u00e3o h\u00e1 porta, caminho de certificado nem bloco de redirecionamento HTTP: ao ver um nome de dom\u00ednio, o Caddy assume 443, obt\u00e9m o certificado e responde na porta 80 com redirecionamento <code>308<\/code> para HTTPS.<\/p>\n<pre><code class=\"language-bash\">sudo mkdir -p \/var\/www\/exemplo\necho '&lt;h1&gt;Ol\u00e1 do Caddy&lt;\/h1&gt;' | sudo tee \/var\/www\/exemplo\/index.html\n\nsudo caddy fmt --overwrite \/etc\/caddy\/Caddyfile\nsudo caddy validate --config \/etc\/caddy\/Caddyfile\nsudo systemctl reload caddy\njournalctl -u caddy --no-pager -n 30<\/code><\/pre>\n<p>O <code>fmt<\/code> padroniza a indenta\u00e7\u00e3o (o Caddyfile usa tabula\u00e7\u00f5es), o <code>validate<\/code> carrega a configura\u00e7\u00e3o sem aplic\u00e1-la e o <code>reload<\/code> troca a configura\u00e7\u00e3o sem reiniciar o processo nem derrubar conex\u00f5es HTTP comuns (WebSockets abertos s\u00e3o encerrados por padr\u00e3o; a op\u00e7\u00e3o <code>stream_close_delay<\/code> do <code>reverse_proxy<\/code> adia esse fechamento). N\u00e3o use <code>restart<\/code> nem <code>stop<\/code> para mudar configura\u00e7\u00e3o: a pr\u00f3pria documenta\u00e7\u00e3o avisa que parar o servi\u00e7o causa indisponibilidade. No log aparece a obten\u00e7\u00e3o do certificado; a partir da\u00ed, a renova\u00e7\u00e3o \u00e9 autom\u00e1tica.<\/p>\n<h2>Proxy reverso com balanceamento<\/h2>\n<p>O uso mais comum do Caddy \u00e9 ficar na frente de aplica\u00e7\u00f5es que escutam s\u00f3 no loopback \u2014 um Gitea, um Vaultwarden, uma API em Node ou Go. Uma linha basta:<\/p>\n<pre><code class=\"language-text\">app.exemplo.com.br {\n\treverse_proxy 127.0.0.1:3000\n}<\/code><\/pre>\n<p>O Caddy j\u00e1 repassa <code>X-Forwarded-For<\/code>, <code>X-Forwarded-Proto<\/code> e <code>X-Forwarded-Host<\/code>, e trata WebSocket sem configura\u00e7\u00e3o extra. Com mais de uma inst\u00e2ncia, liste os destinos e escolha a pol\u00edtica:<\/p>\n<pre><code class=\"language-text\">(seguranca) {\n\theader {\n\t\tStrict-Transport-Security \"max-age=31536000\"\n\t\tX-Content-Type-Options nosniff\n\t\tReferrer-Policy strict-origin-when-cross-origin\n\t\t-Server\n\t}\n}\n\napp.exemplo.com.br {\n\treverse_proxy 127.0.0.1:8080 127.0.0.1:8081 {\n\t\tlb_policy round_robin\n\t\thealth_uri \/healthz\n\t\thealth_interval 10s\n\t}\n\timport seguranca\n\tlog {\n\t\toutput file \/var\/log\/caddy\/app.log\n\t}\n}<\/code><\/pre>\n<p>O bloco entre par\u00eanteses \u00e9 um <em>snippet<\/em>: um trecho reutiliz\u00e1vel que entra em qualquer site com <code>import<\/code>. O <code>-Server<\/code> remove o cabe\u00e7alho que identifica o servidor. A verifica\u00e7\u00e3o ativa de sa\u00fade (<code>health_uri<\/code>) tira do rod\u00edzio a inst\u00e2ncia que parar de responder. O log sai em JSON, uma linha por requisi\u00e7\u00e3o.<\/p>\n<p>Testei exatamente essa configura\u00e7\u00e3o com dois backends: as requisi\u00e7\u00f5es alternaram entre eles, os tr\u00eas cabe\u00e7alhos de seguran\u00e7a chegaram ao cliente, o cabe\u00e7alho <code>Server<\/code> sumiu e o HTTP respondeu <code>308<\/code> para HTTPS. Para validar localmente, sem dom\u00ednio p\u00fablico, troque o nome por <code>app.localhost<\/code>: o Caddy emite o certificado pela CA interna (<code>Caddy Local Authority<\/code>), e o <code>curl -k<\/code> aceita.<\/p>\n<p>Se voc\u00ea vem do nginx, compare com o <a href=\"\/2017\/04\/instalando-gogs-no-ubuntu\/\">bloco de proxy do Gogs<\/a>: s\u00e3o dois <code>server<\/code>, quatro <code>proxy_set_header<\/code> e um certbot \u00e0 parte para fazer o que esse arquivo faz.<\/p>\n<h2>PHP com php-fpm<\/h2>\n<p>Para WordPress, Nextcloud ou qualquer aplica\u00e7\u00e3o PHP, a diretiva <code>php_fastcgi<\/code> j\u00e1 traz as regras de reescrita para <code>index.php<\/code>. Ajuste o caminho do socket \u00e0 vers\u00e3o instalada (8.4 no Debian 13, 8.3 no Ubuntu 24.04):<\/p>\n<pre><code class=\"language-text\">blog.exemplo.com.br {\n\troot * \/var\/www\/blog\n\tphp_fastcgi unix\/\/run\/php\/php8.4-fpm.sock\n\tfile_server\n\tencode zstd gzip\n}<\/code><\/pre>\n<p>O usu\u00e1rio <code>caddy<\/code> j\u00e1 est\u00e1 no grupo <code>www-data<\/code>, o mesmo do php-fpm no Debian e no Ubuntu. Se voc\u00ea usa v\u00e1rias vers\u00f5es de PHP lado a lado, a l\u00f3gica de pools e sockets do post <a href=\"\/2026\/09\/nginx-varias-versoes-php-debian-ubuntu\/\">Nginx e v\u00e1rias vers\u00f5es de PHP<\/a> vale igual \u2014 muda s\u00f3 a linha do <code>php_fastcgi<\/code>.<\/p>\n<h2>Onde ficam certificados, logs e configura\u00e7\u00e3o<\/h2>\n<table>\n<thead>\n<tr>\n<th>Item<\/th>\n<th>Caminho (pacote Debian\/Ubuntu)<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Configura\u00e7\u00e3o<\/td>\n<td><code>\/etc\/caddy\/Caddyfile<\/code><\/td>\n<\/tr>\n<tr>\n<td>Certificados, chaves, conta ACME<\/td>\n<td><code>\/var\/lib\/caddy\/.local\/share\/caddy<\/code><\/td>\n<\/tr>\n<tr>\n<td>CA local (sites <code>.localhost<\/code>)<\/td>\n<td><code>\/var\/lib\/caddy\/.local\/share\/caddy\/pki\/authorities\/local\/root.crt<\/code><\/td>\n<\/tr>\n<tr>\n<td>\u00daltima configura\u00e7\u00e3o JSON salva<\/td>\n<td><code>\/var\/lib\/caddy\/.config\/caddy<\/code><\/td>\n<\/tr>\n<tr>\n<td>Logs do servi\u00e7o<\/td>\n<td><code>journalctl -u caddy<\/code><\/td>\n<\/tr>\n<tr>\n<td>Logs de acesso<\/td>\n<td>onde a diretiva <code>log<\/code> mandar (no exemplo, <code>\/var\/log\/caddy\/<\/code>)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>O diret\u00f3rio de dados precisa ser persistente e entrar no backup: perder <code>\/var\/lib\/caddy<\/code> significa reemitir todos os certificados, o que, com muitos dom\u00ednios, pode esbarrar no limite da CA. Para vari\u00e1veis secretas \u2014 um token de API de DNS, por exemplo \u2014, use um drop-in do systemd em vez de escrever no Caddyfile:<\/p>\n<pre><code class=\"language-bash\">sudo systemctl edit caddy\n# no editor:\n# [Service]\n# EnvironmentFile=\/etc\/caddy\/.env<\/code><\/pre>\n<p>Dentro do Caddyfile, a vari\u00e1vel entra como <code>{env.NOME}<\/code>. A gest\u00e3o de unidades e drop-ins est\u00e1 detalhada em <a href=\"\/2026\/09\/dominando-o-systemd-comandos-essenciais\/\">Dominando o systemd<\/a>.<\/p>\n<h2>A API de administra\u00e7\u00e3o<\/h2>\n<p>Por padr\u00e3o o Caddy abre uma API REST em <code>localhost:2019<\/code>, acess\u00edvel apenas da pr\u00f3pria m\u00e1quina. \u00c9 por ela que o <code>systemctl reload caddy<\/code> (que chama <code>caddy reload<\/code>) entrega a nova configura\u00e7\u00e3o. Voc\u00ea tamb\u00e9m pode consult\u00e1-la:<\/p>\n<pre><code class=\"language-bash\">curl -s localhost:2019\/config\/ | jq .\ncaddy adapt --config \/etc\/caddy\/Caddyfile --pretty | less<\/code><\/pre>\n<p>O primeiro comando mostra a configura\u00e7\u00e3o JSON em execu\u00e7\u00e3o; o segundo, o JSON que o Caddyfile gera \u2014 \u00fatil para entender o que cada diretiva faz por baixo. N\u00e3o exponha a porta 2019 na rede: quem chega nela troca a configura\u00e7\u00e3o do servidor. Se rodar c\u00f3digo n\u00e3o confi\u00e1vel na mesma m\u00e1quina, a documenta\u00e7\u00e3o recomenda isolar processos ou trocar o endere\u00e7o da API por um socket Unix com permiss\u00f5es restritas.<\/p>\n<h2>Docker<\/h2>\n<p>A imagem oficial \u00e9 <code>caddy<\/code> no Docker Hub. Em 5 de outubro de 2026 ela ainda estava na 2.11.6 \u2014 dois dias atr\u00e1s do pacote do apt \u2014, por isso use a tag de s\u00e9rie <code>2.11<\/code>:<\/p>\n<pre><code class=\"language-bash\">docker run -d --name caddy --restart unless-stopped \\\n  -p 80:80 -p 443:443 -p 443:443\/udp \\\n  -v $PWD\/Caddyfile:\/etc\/caddy\/Caddyfile:ro \\\n  -v caddy_data:\/data \\\n  -v caddy_config:\/config \\\n  caddy:2.11<\/code><\/pre>\n<p>O volume <code>\/data<\/code> \u00e9 o equivalente do <code>\/var\/lib\/caddy<\/code>: sem ele, cada recria\u00e7\u00e3o do container pede certificados novos. A publica\u00e7\u00e3o <code>443:443\/udp<\/code> \u00e9 a que habilita o HTTP\/3. Para o b\u00e1sico de containers, veja o <a href=\"\/2017\/08\/curso-de-docker-gratis\/\">curso de Docker<\/a>.<\/p>\n<h2>Plugins: xcaddy e add-package<\/h2>\n<p>O pacote oficial traz s\u00f3 os m\u00f3dulos padr\u00e3o. Plugins \u2014 provedores de DNS para certificados <em>wildcard<\/em>, autentica\u00e7\u00e3o, rate limit \u2014 s\u00e3o compilados dentro do bin\u00e1rio. O caminho recomendado \u00e9 o <a href=\"https:\/\/github.com\/caddyserver\/xcaddy\">xcaddy<\/a>, que precisa do Go instalado:<\/p>\n<pre><code class=\"language-bash\">go install github.com\/caddyserver\/xcaddy\/cmd\/xcaddy@latest\nxcaddy build --with github.com\/caddy-dns\/cloudflare<\/code><\/pre>\n<p>O resultado \u00e9 um bin\u00e1rio <code>.\/caddy<\/code> no diret\u00f3rio atual. Para us\u00e1-lo com o servi\u00e7o do pacote, siga a se\u00e7\u00e3o <a href=\"https:\/\/caddyserver.com\/docs\/build#package-support-files-for-custom-builds-for-debianubunturaspbian\">custom builds<\/a> da documenta\u00e7\u00e3o, que usa <code>dpkg-divert<\/code> para o apt n\u00e3o sobrescrev\u00ea-lo na pr\u00f3xima atualiza\u00e7\u00e3o. Existe tamb\u00e9m o <code>caddy add-package<\/code>, que baixa um bin\u00e1rio com o plugin pronto do servidor de builds do projeto, mas ele ainda \u00e9 marcado como experimental.<\/p>\n<h2>Caddy ou nginx?<\/h2>\n<p>O Caddy vence quando o problema \u00e9 colocar servi\u00e7os atr\u00e1s de HTTPS com pouco atrito: VPS com meia d\u00fazia de aplica\u00e7\u00f5es, homelab, ambientes de teste, ou equipes que n\u00e3o querem cuidar de certbot e renova\u00e7\u00e3o. O nginx continua forte onde j\u00e1 est\u00e1 instalado e afinado, em configura\u00e7\u00f5es muito espec\u00edficas de cache e reescrita, e onde a equipe domina a sintaxe. Nada impede usar os dois: o Caddy na borda cuidando do TLS e o nginx atr\u00e1s servindo uma aplica\u00e7\u00e3o legada.<\/p>\n<p>Se voc\u00ea hospeda servi\u00e7os como o <a href=\"\/2026\/09\/vaultwarden-bitwarden-self-hosted\/\">Vaultwarden<\/a>, o <a href=\"\/2026\/09\/gitea-git-self-hosted-runner-tea\/\">Gitea<\/a> ou o <a href=\"\/2026\/09\/uptime-kuma-no-linux-monitoramento-self-hosted-com-docker-e-nginx\/\">Uptime Kuma<\/a>, troque o bloco de nginx por tr\u00eas linhas de Caddyfile e compare.<\/p>\n<h2>Links<\/h2>\n<ul>\n<li><a href=\"https:\/\/caddyserver.com\/\">caddyserver.com<\/a> \u00b7 <a href=\"https:\/\/caddyserver.com\/docs\/\">documenta\u00e7\u00e3o<\/a> \u00b7 <a href=\"https:\/\/github.com\/caddyserver\/caddy\">github.com\/caddyserver\/caddy<\/a><\/li>\n<li><a href=\"https:\/\/caddyserver.com\/docs\/automatic-https\">Automatic HTTPS<\/a> \u00b7 <a href=\"https:\/\/caddyserver.com\/docs\/caddyfile\/directives\/reverse_proxy\">reverse_proxy<\/a> \u00b7 <a href=\"https:\/\/caddyserver.com\/docs\/running\">Running Caddy (systemd)<\/a><\/li>\n<\/ul>\n<p>Um bin\u00e1rio, um arquivo de configura\u00e7\u00e3o curto e nenhum certbot para lembrar de renovar: \u00e9 essa a proposta do Caddy, e ela se sustenta. Instale pelo reposit\u00f3rio oficial, mantenha <code>\/var\/lib\/caddy<\/code> no backup, deixe a API em <code>localhost<\/code> e use <code>reload<\/code>, nunca <code>restart<\/code>, para aplicar mudan\u00e7as.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Install Caddy on Ubuntu and Debian via the official repository and put sites and applications behind automatic HTTPS, with reverse proxy, load balancing, PHP, Docker, and plugins.<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11,2,111,120,3],"tags":[524,14,525,240,526,203,475],"class_list":["post-1789","post","type-post","status-publish","format-standard","hentry","category-debian","category-linux","category-opensource","category-servidores","category-ubuntu","tag-caddy","tag-howto","tag-https","tag-nginx","tag-proxy-reverso","tag-self-hosted","tag-tls"],"_links":{"self":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/posts\/1789","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/comments?post=1789"}],"version-history":[{"count":1,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/posts\/1789\/revisions"}],"predecessor-version":[{"id":1790,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/posts\/1789\/revisions\/1790"}],"wp:attachment":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/media?parent=1789"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/categories?post=1789"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/tags?post=1789"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}