Temos um servidor WordPress de pilha LAMP que serve a maioria dos recursos corretamente. No entanto, o arquivo CSS de um plugin e várias imagens estão retornando soft 404s aproximadamente 20% do tempo. Não consigo encontrar qualquer referência ao 404 nos logs de acesso, mas o navegador está definitivamente recebendo uma resposta 404 de algum lugar (WordPress, eu diria).
Quando uso um URL de alias que não corresponde ao URL do site, mas sim ao caminho do recurso, o recurso é carregado corretamente 100% do tempo. No entanto, o uso do URL do site só resolve os ativos selecionados e problemáticos em 20% do tempo.
Você pode testar um dos recursos problemáticos aqui: link
No entanto, o link do alias sempre é resolvido corretamente: link
Estranho, se eu tentar acessar conteúdo desatualizado que definitivamente não existe no servidor, na URL ativa ele retorna o conteúdo aproximadamente 50% do tempo. Usando o link de alias, ele é 100% do tempo - o comportamento correto.
O log de erros e o log de erros do PHP estão limpos.
Um log de acesso de amostra (extraído de grep 'zero-cost.jpg' /var/log/httpd/mr-eco-access_log ) de várias atualizações do link direto ao vivo (onde não estou vendo nenhum 404):
10.166.202.202 - - [28/May/2014:20:27:41 +0000] "GET /wp-content/uploads/2014/05/zero-cost.jpg HTTP/1.1" 304 -
10.166.202.202 - - [28/May/2014:20:27:42 +0000] "GET /wp-content/uploads/2014/05/zero-cost.jpg HTTP/1.1" 304 -
10.166.202.202 - - [28/May/2014:20:27:43 +0000] "GET /wp-content/uploads/2014/05/zero-cost.jpg HTTP/1.1" 304 -
10.166.202.202 - - [28/May/2014:20:27:43 +0000] "GET /wp-content/uploads/2014/05/zero-cost.jpg HTTP/1.1" 304 -
10.176.201.37 - - [28/May/2014:20:27:56 +0000] "GET /wp-content/uploads/2014/05/zero-cost.jpg HTTP/1.1" 200 57027
As ferramentas de desenvolvimento do Chrome listam a seguinte atividade de rede antes de exibir o conteúdo da página 404:
zero-cost.jpg /wp-content/uploads/2014/05 GET 404 Not Found text/html Other 15.9 KB 73.2 KB 953 ms 947 ms
Minha configuração do Apache é padrão, listei a entrada do host virtual e o arquivo .htaccess abaixo. Eu posso fornecer outras partes da configuração do Apache, se necessário.
Host virtual:
<VirtualHost *:80>
DocumentRoot /var/www/public_html/mr-eco.wordpress.promocampaigns.com
ServerName www.mreco.org
ServerAlias mreco.org mr-eco.wordpress.promocampaigns.com
ErrorLog logs/mr-eco-error_log
CustomLog logs/mr-eco-access_log common
<Directory /var/www/public_html/mr-eco.wordpress.promocampaigns.com>
AllowOverride All
SetOutputFilter DEFLATE
</Directory>
</VirtualHost>
.htaccess:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Eu verifiquei vários registros A e posso confirmar que há um único registro A apontando para o domínio:
;; ANSWER SECTION:
mreco.org. 60 IN A 50.18.58.174
Sou relativamente novo na administração de sistemas e com uma perda completa do que poderia causar isso. No passado, os ativos 404 de maneira inconsistente eram causados por instâncias fora de sincronização por trás de um balanceador de carga. Nesse caso, é uma instância única por trás do balanceador de carga.
Por causa da inconsistência, parece um problema de cache. Nós não fazemos uso do cache do Apache, e até onde eu sei, o WordPress não deveria estar em cache também.
O que eu fiz até agora:
Estou com uma perda total. Obrigado por me ajudar!
Atualizar
A navalha de Occam se aplica. Na verdade, havia instâncias múltiplas e fora de sincronia sob um balanceador de carga. Eu estava simplesmente olhando para o balanceador de carga incorreto inicialmente. Obrigado pelo seu tempo.