- Este tópico contém 3 respostas, 2 vozes e foi atualizado pela última vez 5 anos, 1 mês atrás por
.
-
Posts
-
O NginX por padrão trata os erros do site, mas nem sempre isso é o ideal. Na minha opinião fica muito melhor quando o próprio site faz este tratamento. Erroneamente alguns leitores pensam que isso é um problema no ISPConfig.
Por exemplo acesse este link: https://fatorbinario.com/essa_pagina_nao_existe_no_fator
Note que customizei a minha página de Erro 404.
Para fazer isso abra o painel do ISPConfig e navegue até:
ISPConfig -> Sites -> Selecione o site -> Aba Opções -> Diretivas NginXE insira o seguinte bloco de diretivas:
*ATENÇÃO: Eu negritei a quarta linha porque você tem que substituir “web1” por seu código do site que aparece no ISPConfig. Nessa mesma tela de Opções isso aparece no terceiro campo “Usuário Linux” ou no campo “open_basedir do PHP” logo abaixo. Negritei também a linha de “intercept errors” que deve ser alterada para “off“, isso fará com que o NginX deixe o tratamento de exceções para o próprio site.location @php { try_files $uri =404; include /etc/nginx/fastcgi_params; fastcgi_pass unix:/var/lib/php5-fpm/web1.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_intercept_errors off; }*Caso você esqueça de substituir o web1.sock para o ID de site correto ao acessar o site (WordPress) será exibida uma mensagem de erro igual a esta: “No input file specified”
Para saber de onde esse código foi extraido abra o SSH do servidor com as credenciais de root e carregue o diretório /etc/nginx/sites-enabled/ e selecione o vHost do domínio a alterar. Role a tela até a linha 92. *Importante: Nunca altere o bloco NginX diretamente no arquivo vhost pois qualquer alteração será perdida uma vez que o ISPConfig sobrescreve o que estiver ali. Sempre que quiser alterar um bloco completo como esse copie-o inteiro para a caixa de diretivas.
* Se você seguiu outro tutorial que não seja de ISPConfig encontre o código parecido dentro do arquivo NginX para o site.
Para customizar a página no WordPress, de preferência use Temas Child (filho), e modifique o arquivo 404.php conforme melhor lhe agrade.
Para sites que não sejam WordPress verifique qual o arquivo de tratamento de erros.
Com essa alteração também será possível usar o famigerado plugin “Site em Manutenção” que muitos sites utilizam em fase de desenvolvimento. E também tratará de algumas exceções quando der o Error 503 – Service Unavailable.
Estou com esse mesmo problema no Joomla, onde fica dando erro 503 quando ativo o modo de manutenção. Acredito que essa diretiva resolverá o problema, mas percebi que o parâmetro fastcgi_pass unix está com o caminho do php5. Acho que esse caminho se refere ao php do tutorial do Debian 8. No caso do Debian 9 (que tem 3 versões de PHP), qual seria o substituto?
Edson comentou no post #13607:
Estou com esse mesmo problema no Joomla, onde fica dando erro 503 quando ativo o modo de manutenção. Acredito que essa diretiva resolverá o problema, mas percebi que o parâmetro fastcgi_pass unix está com o caminho do php5. Acho que esse caminho se refere ao php do tutorial do Debian 8. No caso do Debian 9 (que tem 3 versões de PHP), qual seria o substituto?Esse aqui:
fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;Independente da versão que escolher, porque isso ae é definido por padrão no menu de configuração do sistema.
Luis FatorBinario comentou no post #13608:Esse aqui:
fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
Independente da versão que escolher, porque isso ae é definido por padrão no menu de configuração do sistema.Tentei o caminho sugerido, do jeito que você postou e não funcionou no Joomla. Também tentei colocar o web(número).sock como sugerido no início do post para ver se era isso, mas também sem resultado. Quando ativo a página de manutenção nativa do Joomla, continua aparecendo a página de erro 503.
- Você deve fazer login para responder a este tópico.