Cache FastCGI no Alpine Linux 3.22: guia WordPress com Nginx

17 min de leitura  ·  Guia técnico

Cache FastCGI WordPress no Alpine Linux 3.22 é o procedimento para fazer o Nginx armazenar páginas públicas geradas pelo PHP-FPM e entregá-las sem executar o WordPress em toda requisição. Para melhorar desempenho do WordPress com esse recurso, siga estes passos:

1. Confirme que o WordPress já responde via Nginx e PHP-FPM no Alpine Linux 3.22.
2. Crie o diretório de cache com dono e permissões compatíveis com o processo do Nginx.
3. Declare a zona fastcgi_cache no arquivo principal do Nginx.
4. Adicione regras de bypass para login, wp-admin, usuários autenticados, carrinho e URLs dinâmicas.
5. Inclua um cabeçalho de teste para validar MISS, BYPASS e HIT com curl.
6. Recarregue os serviços e monitore logs antes de liberar em produção.

Pré-requisitos

• Acesso root ou usuário com privilégios equivalentes no Alpine Linux 3.22.
• WordPress já instalado e funcionando com Nginx e PHP-FPM.
• Pacotes Nginx e PHP-FPM instalados no Alpine, preferencialmente com PHP 8.4 quando disponível no repositório usado.
• Domínio apontando para o servidor e site acessível por HTTP ou HTTPS.
• Conhecimento do arquivo de configuração do bloco do site, por exemplo em /etc/nginx/http.d/.
• Backup recente dos arquivos de configuração do Nginx antes de alterar cache, regras de localização ou parâmetros FastCGI.

Configuração do Nginx FastCGI cache para WordPress

Cache FastCGI para WordPress no Alpine Linux 3.22 deve ser configurado no Nginx com cuidado porque o WordPress mistura páginas públicas, área administrativa, sessão de login e cookies. O objetivo é armazenar apenas HTML público e permitir que requisições sensíveis continuem chegando ao PHP-FPM. Antes de mexer na configuração, confirme os serviços ativos e faça uma cópia dos arquivos que serão editados. Se você acessa o servidor pela primeira vez, o artigo Acessando servidores VPS Linux da AviraHost ajuda a validar o acesso remoto sem misturar este procedimento com outras camadas.

1. Verifique o sistema e os serviços.
2. Faça backup da configuração atual do Nginx.
3. Teste a sintaxe antes de qualquer reload.

cat /etc/alpine-release
rc-service nginx status
rc-service php-fpm84 status

Output esperado:
3.22.x
* status: started
* status: started

Se o serviço PHP-FPM tiver outro nome no seu Alpine, liste os serviços disponíveis e ajuste os comandos seguintes para o nome correto. Ao rodar este comando, você verá apenas nomes locais do OpenRC, sem alterar configuração.

rc-status | grep -E "nginx|php"

Output esperado:
nginx                                                             [ started ]
php-fpm84                                                         [ started ]

Atenção: antes de editar qualquer arquivo, copie a configuração atual. Esse backup não limpa cache nem muda o site; ele apenas permite voltar rapidamente se houver erro de sintaxe.

cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak
cp -a /etc/nginx/http.d /etc/nginx/http.d.bak

Output esperado:
sem saída quando a cópia é concluída com sucesso

Criar diretório e zona de cache FastCGI no Nginx

Zona fastcgi_cache no Nginx é a área nomeada que controla onde o cache fica no disco e como o Nginx consulta os objetos armazenados. No Alpine Linux 3.22, uma configuração simples costuma separar a declaração global da regra do site: a zona fica no contexto http, enquanto as regras de WordPress ficam no bloco do domínio. Esse desenho facilita manutenção, evita duplicação e reduz o risco de ativar cache em local errado. Para mais práticas gerais de otimização de ambiente Linux, veja também Dicas de Otimização de Servidores Linux, mantendo aqui o foco no Nginx FastCGI.

1. Crie o diretório persistente do cache.
2. Ajuste o dono para o usuário que executa o Nginx.
3. Declare a zona dentro do contexto http.

mkdir -p /var/cache/nginx/fastcgi_wordpress
chown -R nginx:nginx /var/cache/nginx
chmod 700 /var/cache/nginx/fastcgi_wordpress

Output esperado:
sem saída quando diretório, dono e permissões são aplicados com sucesso

Agora edite /etc/nginx/nginx.conf e adicione a diretiva abaixo dentro do bloco http. Não coloque essa linha dentro de server ou location, pois a zona precisa existir antes de ser chamada pelo bloco do site.

fastcgi_cache_path /var/cache/nginx/fastcgi_wordpress levels=1:2 keys_zone=WORDPRESS:100m inactive=60m use_temp_path=off;

Output esperado ao testar depois:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

A opção keys_zone=WORDPRESS:100m cria uma área de metadados em memória para o cache. O diretório em disco guarda as respostas e o Nginx usa a zona para localizar os itens. Evite criar várias zonas para o mesmo site sem necessidade, porque isso complica invalidação e diagnóstico. O valor de inactive controla por quanto tempo um item não acessado pode permanecer antes de expirar por inatividade.

nginx -t

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

Configurar bypass de cache para WordPress no Alpine Linux 3.22

Bypass de cache no WordPress é a parte mais importante da configuração, porque impede que páginas administrativas, login, comentários, carrinho e conteúdo personalizado sejam servidos como HTML público. O FastCGI cache é excelente para posts, páginas e home pública, mas não deve armazenar respostas que dependem de cookie de usuário autenticado. A lógica abaixo cria uma variável simples chamada $skip_cache e muda seu valor quando a requisição não deve ser cacheada.

Edite o bloco do domínio em /etc/nginx/http.d/seusite.conf. Adapte server_name, root e o caminho do Unix Socket do PHP-FPM para o seu ambiente. O exemplo usa PHP-FPM 8.4 via socket local, um padrão comum quando Nginx e PHP-FPM rodam no mesmo Alpine. Essa abordagem via Unix Socket reduz latência de comunicação entre os processos em comparação com TCP local.

server {
    listen 80;
    server_name exemplo.com.br www.exemplo.com.br;
    root /var/www/wordpress;
    index index.php index.html;

    set $skip_cache 0;

    if ($request_method = POST) {
        set $skip_cache 1;
    }

    if ($query_string != "") {
        set $skip_cache 1;
    }

    if ($request_uri ~* "/wp-admin/|/wp-login.php|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap") {
        set $skip_cache 1;
    }

    if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in|woocommerce_items_in_cart|woocommerce_cart_hash") {
        set $skip_cache 1;
    }

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include fastcgi.conf;
        fastcgi_pass unix:/run/php-fpm84/php-fpm.sock;

        fastcgi_cache WORDPRESS;
        fastcgi_cache_valid 200 301 302 60m;
        fastcgi_cache_bypass $skip_cache;
        fastcgi_no_cache $skip_cache;
        fastcgi_cache_use_stale error timeout updating invalid_header http_500 http_503;
        add_header X-FastCGI-Cache $upstream_cache_status always;
    }

    location ~* /(?:uploads|files)/.*\.php$ {
        deny all;
    }
}

Output esperado ao salvar e testar:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

O cabeçalho X-FastCGI-Cache é proposital. Ele mostra se a requisição foi armazenada, servida do cache ou ignorada por regra de bypass. Em produção, muitos administradores mantêm esse cabeçalho durante a fase de validação e removem depois, mas ele é extremamente útil para confirmar se uma URL pública está retornando MISS na primeira chamada e HIT nas seguintes.

nginx -t

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

Recarregar Nginx e validar HIT, MISS e BYPASS

Teste de cache com curl evita ativar uma configuração às cegas. Depois que a sintaxe estiver correta, recarregue o Nginx sem derrubar o serviço e faça requisições controladas. A primeira chamada para uma página pública tende a retornar MISS, pois o objeto ainda será gravado. A segunda chamada, se a URL for cacheável, deve retornar HIT. Já URLs como /wp-login.php e /wp-admin/ devem retornar BYPASS. Esse comportamento impacta diretamente o TTFB (Time to First Byte): páginas servidas com HIT eliminam o processamento do PHP-FPM e entregam respostas muito mais rápidas, o que contribui positivamente para os Core Web Vitals do site.

1. Recarregue o Nginx no Alpine Linux 3.22.
2. Teste uma página pública duas vezes.
3. Teste login e área administrativa para confirmar bypass.
4. Confira se arquivos aparecem no diretório de cache.

rc-service nginx reload

Output esperado:
* Reloading nginx configuration ...

curl -I http://exemplo.com.br/

Output esperado na primeira requisição:
HTTP/1.1 200 OK
X-FastCGI-Cache: MISS

curl -I http://exemplo.com.br/

Output esperado nas próximas requisições cacheáveis:
HTTP/1.1 200 OK
X-FastCGI-Cache: HIT

curl -I http://exemplo.com.br/wp-login.php

Output esperado para login:
HTTP/1.1 200 OK
X-FastCGI-Cache: BYPASS

find /var/cache/nginx/fastcgi_wordpress -type f | head

Output esperado:
lista de arquivos de cache quando páginas públicas já foram acessadas

Se a primeira página pública sempre retornar BYPASS, revise cookies, query strings e regras de URI. Se retornar MISS repetidamente, verifique permissões do diretório de cache e se o Nginx consegue gravar em /var/cache/nginx/fastcgi_wordpress. Não valide apenas pelo navegador, porque extensões, cookies de sessão e login no painel do WordPress podem mudar o comportamento.

Limpeza segura do cache FastCGI no WordPress

Limpar cache FastCGI do WordPress deve ser uma ação controlada, principalmente após alterar tema, menus, widgets ou conteúdo global. O Nginx não sabe, sozinho, que um post foi atualizado no painel; ele apenas respeita as regras e o tempo de validade configurado. Por isso, a limpeza manual é útil em implantação, atualização visual ou teste de regra. Em ambientes com muito conteúdo dinâmico, prefira tempos de cache menores e bypass bem definido em vez de tentar armazenar tudo. Uma abordagem conhecida como microcaching — em que o tempo de validade é reduzido para 1 a 5 segundos — pode ser útil para sites com atualizações frequentes que ainda precisam de algum alívio no PHP-FPM.

Atenção: o comando abaixo remove os arquivos de cache do diretório configurado. Ele não remove WordPress, banco de dados, uploads nem configurações do Nginx, mas deve apontar exatamente para o diretório de cache para evitar exclusão indevida.

rm -rf /var/cache/nginx/fastcgi_wordpress/*
rc-service nginx reload

Output esperado:
* Reloading nginx configuration ...

Após limpar, repita o teste com curl. Uma resposta pública deve voltar a MISS na primeira chamada e HIT nas seguintes. Esse ciclo confirma que o Nginx está gravando novos objetos e que a limpeza não quebrou a zona declarada no arquivo principal.

curl -I http://exemplo.com.br/ && curl -I http://exemplo.com.br/

Output esperado:
X-FastCGI-Cache: MISS
X-FastCGI-Cache: HIT

Para uma rotina operacional simples, documente quando limpar o cache: troca de tema, alteração estrutural de página inicial, mudança de menu, atualização de plugin que altera HTML público ou publicação que precisa aparecer imediatamente. Não use limpeza total a cada minuto sem necessidade, porque isso reduz o benefício do cache e aumenta trabalho do PHP-FPM.

Problemas comuns e como resolver

Sintoma: X-FastCGI-Cache sempre retorna MISS

Causa: o Nginx pode não estar gravando no diretório de cache, a zona pode estar fora do contexto correto ou a resposta pode não ser considerada cacheável. Solução: confirme permissões em /var/cache/nginx/fastcgi_wordpress, rode nginx -t, acesse a mesma URL pública duas vezes sem cookies de login e verifique se arquivos aparecem com find.

ls -ld /var/cache/nginx/fastcgi_wordpress
find /var/cache/nginx/fastcgi_wordpress -type f | head

Output esperado:
diretório com dono nginx e arquivos de cache após acesso público

Sintoma: wp-admin ou wp-login.php aparece como HIT

Causa: as regras de bypass não cobrem corretamente a URI administrativa ou a configuração do bloco PHP foi aplicada sem fastcgi_cache_bypass e fastcgi_no_cache. Solução: revise as condições de $skip_cache, teste login com curl e não libere produção até que áreas administrativas retornem BYPASS.

curl -I http://exemplo.com.br/wp-login.php

Output esperado:
X-FastCGI-Cache: BYPASS

Sintoma: página pública retorna conteúdo antigo depois de editar o WordPress

Causa: o HTML anterior ainda está armazenado no cache FastCGI e o tempo de validade ainda não expirou. Solução: limpe o diretório de cache após mudanças relevantes, recarregue o Nginx e teste novamente com curl. Se isso acontecer com frequência, reduza o tempo de fastcgi_cache_valid ou ajuste o fluxo editorial.

rm -rf /var/cache/nginx/fastcgi_wordpress/*
rc-service nginx reload

Output esperado:
* Reloading nginx configuration ...

Sintoma: erro 502 após ativar cache FastCGI

Causa: o socket do PHP-FPM no fastcgi_pass pode estar incorreto, o serviço PHP-FPM pode estar parado ou o arquivo de configuração pode ter sido alterado junto com o cache. Solução: verifique o status do PHP-FPM, confirme o caminho do Unix Socket e teste a sintaxe do Nginx antes de recarregar novamente.

rc-service php-fpm84 status
ls -l /run/php-fpm84/
nginx -t

Output esperado:
* status: started
php-fpm.sock listado no diretório
syntax is ok

Perguntas frequentes sobre cache FastCGI no WordPress

O que é cache FastCGI no WordPress?

Cache FastCGI no WordPress é uma técnica em que o Nginx armazena respostas geradas pelo PHP-FPM para entregar páginas sem processar o PHP a cada visita. Ele é útil para reduzir trabalho do servidor em páginas públicas, mas precisa de regras de bypass para login, carrinho, painel administrativo e usuários autenticados.

Cache FastCGI funciona no Alpine Linux 3.22?

Sim, o cache FastCGI pode ser usado no Alpine Linux 3.22 quando o WordPress roda com Nginx e PHP-FPM. A configuração exige diretório de cache, zona fastcgi_cache, regras no bloco do site e validação dos serviços após cada alteração.

Preciso usar plugin de cache no WordPress junto com FastCGI?

Não é obrigatório usar plugin de cache quando o Nginx FastCGI cache está configurado corretamente para páginas HTML. Plugins ainda podem ser úteis para minificação, imagens ou limpeza de cache, mas dois caches de página ativos ao mesmo tempo podem dificultar diagnóstico e invalidação.

Como saber se o FastCGI cache está funcionando no WordPress?

A forma prática é adicionar um cabeçalho de status no Nginx, como X-FastCGI-Cache, e testar a página com curl. Em geral, a primeira requisição tende a gravar o cache e as próximas devem retornar HIT quando a URL puder ser armazenada.

Quando não devo ativar cache FastCGI no WordPress?

Evite cache FastCGI sem regras específicas em áreas com conteúdo personalizado por usuário, checkout, carrinho, wp-admin, páginas de login e aplicações com sessões dinâmicas. Nesses casos, o bypass precisa ser configurado antes da ativação para não entregar conteúdo incorreto a visitantes.

Conclusão

• Configure a zona FastCGI no contexto http do Nginx e mantenha as regras do WordPress no bloco do domínio.
• Valide MISS, HIT e BYPASS com curl antes de considerar o cache ativo em produção.
• Documente uma rotina de limpeza segura para alterações de tema, menu, página inicial e conteúdo crítico.

Precisa de suporte para otimizar seu WordPress com Nginx?

Uma hospedagem bem ajustada facilita manter WordPress, Nginx e PHP-FPM funcionando com cache previsível, sem misturar páginas públicas com sessões administrativas. Se você prefere focar no site, conte com uma estrutura preparada para projetos WordPress.

Conheça a hospedagem de sites da AviraHost

Leia também

• Passo a passo para configurar Nginx com PHP-FPM no VPS Linux: Guia Completo
• Otimizar o Desempenho do Nginx com Cache Avançado em VPS Linux e Servidor Dedicado
• Otimizar Nginx + PHP-FPM no mesmo servidor: conflitos