Erro 403 Forbidden: o que é e como resolver no seu site
Entenda o erro 403 Forbidden no Nginx: leia o log, confira o arquivo de índice, as permissões e as regras deny, e saiba o que evitar ao tentar resolver.
Por Redação Eleven Host · @robson.direitodigital · 28 de outubro de 2026 · 7 min de leitura

Capa da Redação Eleven Host para o guia: Erro 403 Forbidden: o que é e como resolver no seu site Arte: Eleven Host
O erro 403 forbidden significa que o servidor entendeu o pedido e se recusa a entregar a página. Na VPS com Nginx, leia o log de erros e confira três pontos: arquivo de índice, permissões e regras deny.
Este guia é para quem tem um site numa VPS com Nginx e recebeu a tela de 403 ao abrir o endereço. A ordem segue o diagnóstico: o que o erro quer dizer, o que cabe ao visitante, como ler o log e quatro causas para checar. O nome seudominio.com.br é um exemplo. Troque pelo seu.
O que significa o erro 403 Forbidden
Segundo a MDN, o código de resposta de status de erro do cliente HTTP 403 Forbidden indica que o servidor entendeu o pedido, mas se recusa a autorizá-lo. A MDN compara com o 401 e explica que, no 403, a nova autenticação não fará diferença.
Em linguagem simples: o servidor achou o endereço, mas não quer (ou não pode) entregar o conteúdo. É diferente de outros erros que você pode ver no mesmo site:
- 403: o servidor encontrou o pedido e recusou entregar.
- 404: o servidor não achou o que foi pedido.
- 502 e 504: o programa de trás do Nginx falhou ou demorou. Os guias Erro 502 Bad Gateway: o que é e como resolver na VPS e Erro 504 Gateway Timeout: o que é e como resolver na VPS tratam esses dois casos.
Resumindo: no 403 o servidor está de pé e respondendo. A recusa pode vir de uma regra, de uma permissão, da falta de um arquivo ou de um plugin.
Se você é visitante ou dono do site
Se você só está visitando o site de outra pessoa, há pouco a fazer do seu lado: confira se digitou o endereço certo e tente de novo mais tarde. A decisão de recusar está no servidor dele.
Se o site é seu e roda numa VPS, o motivo está na configuração ou nas permissões. Os passos abaixo mostram como descobrir qual das causas é a sua.
Passo 1: ler o log de erros do Nginx
O log de erros do Nginx pode mostrar o motivo da recusa. Veja as últimas 50 linhas do log:
sudo tail -n 50 /var/log/nginx/error.log
Duas mensagens que podem aparecer, e o que cada uma indica:
directory index of "/var/www/seudominio.com.br/" is forbidden: a pasta não tem arquivo de índice (passo 2).(13: Permission denied): o Nginx não consegue ler o arquivo ou a pasta (passo 3).
Se o log mostrar outra mensagem, leia a linha inteira antes de mexer na configuração. Se não aparecer nada relacionado, o bloqueio pode vir de uma regra de acesso (passo 4) ou de um plugin (passo 5).
Para resolver o 403, não abra tudo. Liberar permissão total ou ligar a listagem de pastas pode fazer o erro sumir, mas expõe arquivos. Ache a causa no log e corrija só o que está errado.
Passo 2: pasta sem arquivo de índice
A diretiva index do Nginx define os arquivos usados como página inicial de uma pasta. Eles são conferidos na ordem, e o padrão é index index.html;.
Se a pasta do site não tem nenhum desses arquivos, o Nginx procura a listagem de pastas, que é feita pelo módulo autoindex. Segundo a documentação do Nginx, ele vem desligado (autoindex off;). Sem índice e com a listagem desligada, a resposta é 403.
Confira o que existe na pasta do site:
ls -la /var/www/seudominio.com.br/
Se o site é em PHP ou WordPress, o bloco server precisa listar o index.php. A linha fica assim, como no guia Instalar WordPress na VPS: passo a passo com Nginx:
index index.php index.html;
Não ligue o autoindex on; para fazer o erro sumir. Isso mostra a lista de arquivos da pasta para quem visitar o endereço. O caminho certo é ter o arquivo de índice no lugar e apontado na diretiva index.
Passo 3: permissões de arquivos e pastas
O Nginx precisa ler o arquivo e também atravessar cada pasta do caminho até ele. Uma pasta no meio do caminho sem permissão já pode causar o 403 no arquivo lá no fim.
O comando namei segue o caminho e, com a opção -l, mostra as permissões de cada parte, no estilo do ls:
namei -l /var/www/seudominio.com.br/index.php
Olhe cada linha da saída: dono, grupo e permissões de cada pasta do caminho. Procure uma pasta ou o arquivo que o usuário do Nginx não consiga ler.
A documentação do WordPress recomenda pastas com permissão 755 ou 750, arquivos com 644 ou 640 e o wp-config.php com 440 ou 400. Para ajustar um site inteiro a esses valores, rode os dois comandos abaixo. Eles mudam as permissões de tudo dentro da pasta e deixam também o wp-config.php em 644. Confirme o caminho antes de executar:
sudo find /var/www/seudominio.com.br -type d -exec chmod 755 {} \;
sudo find /var/www/seudominio.com.br -type f -exec chmod 644 {} \;
Não use 777. A documentação do WordPress alerta que essa permissão deixa os arquivos acessíveis e modificáveis por outros usuários e processos, e orienta: quando vir 777, pergunte por que ele é necessário.
Quer um servidor para hospedar o seu site? VPS a partir de R$ 17,00/mês no Plano Bronze; confira na loja o que cada plano inclui. Ver planos de VPS
Passo 4: regra deny esquecida
As diretivas allow e deny do Nginx são conferidas em sequência, até a primeira que casar com o visitante. O deny all; nega quem sobrou.
Por isso, um deny esquecido dá 403 para quem está de fora. Um exemplo: uma área do site restrita a um IP. Procure as regras nos sites ativos:
sudo grep -rn "deny" /etc/nginx/sites-enabled/
Cada linha da saída mostra o arquivo e o número da linha. Abra o arquivo, veja em qual location ou bloco a regra está e confira se ela deveria mesmo valer para aquele endereço.
Passo 5: plugin de segurança ou firewall de aplicação
Se o log do Nginx não aponta nada, o bloqueio pode vir de outra camada: um plugin de segurança do seu site ou um firewall de aplicação que barra o IP do visitante. Nesse caso, a recusa vem da regra dessa camada, e não do Nginx.
Para testar, desative um por vez e recarregue a página. Se o 403 sumir, você achou o responsável. Aí revise as regras dele e reative-o, em vez de deixá-lo desligado. Se o site inteiro saiu do ar e você precisa de um roteiro mais amplo, veja Site fora do ar: o que fazer, passo a passo.
Testar e recarregar o Nginx
Depois de mexer na configuração do Nginx, teste a sintaxe antes de aplicar:
sudo nginx -t
Se o teste apontar erro, não recarregue: corrija a linha indicada. Estando tudo certo, recarregue:
sudo systemctl reload nginx
Depois abra o endereço do site e confira se o 403 saiu. Se continuar, volte ao log do passo 1: a mensagem nova pode apontar outra causa.
Checklist do 403
- Li o
error.logdo Nginx e anotei a mensagem. - Conferi se a pasta do site tem o arquivo de índice (
index.phpouindex.html). - Conferi a diretiva
indexno blocoserver. - Rodei o
namei -le olhei as permissões de cada pasta do caminho. - Ajustei para 755 nas pastas e 644 nos arquivos, sem usar 777.
- Procurei regras
denycom ogrep. - Desativei um plugin de segurança por vez, para testar.
- Rodei
nginx -tantes de recarregar.
Já pensou no endereço do seu site? Busque o nome e registre o seu domínio na Eleven Host. Registrar domínio
Perguntas frequentes
O erro 403 Forbidden é problema do meu navegador?
Segundo a MDN, o 403 indica que o servidor entendeu o pedido e se recusa a autorizá-lo. Como a recusa vem do servidor, o que você tem a fazer do seu lado é conferir o endereço e tentar mais tarde.
Qual a diferença entre o 403 e o 404?
No 404, o servidor não achou o que foi pedido. No 403, ele entendeu o pedido e recusou entregar.
Posso ligar o autoindex para resolver o 403?
Não é o caminho. A listagem de pastas, que o autoindex on; liga, mostra os arquivos da pasta a quem visitar o endereço. Coloque o arquivo de índice no lugar certo.
Posso usar a permissão 777 para o erro sumir?
Não. A documentação do WordPress alerta que o 777 deixa os arquivos acessíveis e modificáveis por outros usuários e processos. Use 755 nas pastas e 644 nos arquivos.