BK-230 - Meta feed de pecas com imagens bloqueadas

Contexto inicial

• catálogo afetado:
• Products for Rio No Teatro (105537999536136)
• fonte de dados:
• FEED PEÇAS
• tipo:
• Arquivo de dados (Programado)
• arquivo de dados:
• https://rionoteatro.com.br/pecas.xml
• execução reportada:
• 2026-04-08 02:01 GMT-03:00

Sintoma reportado

• o carregamento do feed atualizou/adicionou 3 produtos
• 0 removidos
• 0 falhas de carregamento
• 1 problema
• mensagem principal da Meta:
• A Meta pode estar sendo impedida de acessar a imagem
• efeito reportado:
• 1 item não exibido em lojas ou anúncios

Texto do alerta da Meta

• O firewall do seu site pode estar bloqueando nosso acesso à imagem do produto. Verifique se o seu site está bloqueando a Meta e se o arquivo de imagem não está protegido por senha.

Objetivo

• descobrir por que a Meta consegue ler o pecas.xml, mas falha ao acessar ao menos uma imagem de produto
• confirmar se o bloqueio está em:
• firewall/WAF
• hotlink/rate-limit
• permissão/ACL do arquivo
• URL incorreta no feed
• redirecionamento/cdn/cache
• proteção por agente/IP que afete o crawler da Meta

Primeiras frentes de análise

• inspecionar os image_link gerados no pecas.xml
• identificar qual dos 3 produtos carregados gerou o problema
• testar acesso HTTP real às imagens com user-agent próximo ao crawler da Meta
• revisar regras de firewall, hotlink e bloqueios por user-agent/IP no domínio
• validar se a URL da imagem responde 200 sem exigir cookie, sessão ou referrer
• comparar se o mesmo asset abre normalmente em navegador comum, curl simples e curl com user-agent de bot

Evidências já conhecidas

• a fonte de dados em si continua acessível pela Meta
• o problema atual parece restrito ao fetch da imagem, não ao download do XML

Evidências confirmadas nesta sessão

• o relatório .xlsx da Meta apontou inicialmente o item 1493
• título afetado no relatório:
• Fanáticos 75%OFF Ipanema
• URL reportada no feed no momento inicial:
• https://rionoteatro.com.br/arquivos/pecas/1493/media/fanaticosrionoteatro.png
• as 3 peças do feed foram comparadas em disco e por HTTP:
• 1341
• 1493
• 1342
• resultado da comparação:
• mesmas permissões de diretório (755)
• mesmas permissões de arquivo (644)
• mesmo owner/grupo (www:www)
• todas respondendo HTTP 200
• todas baixando integralmente com user-agent da Meta
• media e large idênticas em conteúdo para as três peças

Mudança aplicada no feed

• o gerador atualizar_feed.php foi ajustado para usar /large/ em vez de /media/
• após essa troca, a Meta passou a reportar problema nas 3 imagens do feed
• isso reforçou a hipótese de bloqueio de origem externa, e não defeito isolado de um arquivo

Infraestrutura encontrada

• o domínio possui geoblock por país no vhost Nginx:
• arquivo: /www/server/panel/vhost/nginx/rionoteatro.com.br.conf
• regra principal encontrada:
• IPs com país diferente de BR recebem 403
• isso é compatível com crawler da Meta vindo de fora do Brasil
• o ambiente local da VPS não reproduzia o bloqueio porque acessos locais passam no bypass interno

Mitigação aplicada nesta rodada

• foi criada exceção mínima no vhost para manter o geoblock geral, mas liberar:
• /pecas.xml
• /pecas_inteira.xml
• /arquivos/pecas//media/
• /arquivos/pecas//large/
• nginx -t validado com sucesso
• nginx reload executado com sucesso
• depois do log mostrar 403 para o crawler meta-externalads/1.1, o allowlist de user-agents Meta no access_by_lua_block também foi ampliado para incluir:
• meta-externalads
• nginx -t validado novamente com sucesso
• nginx reload executado novamente com sucesso

Evidência nova do log da Meta

• o access log mostra a Meta buscando as imagens diretamente e recebendo sucesso:
• 2026-04-08 03:12:36 -03
• GET /arquivos/pecas/1341/large/o-otimismo-que-faz-o-besouro-voarrionoteatro.png -> 200
• GET /arquivos/pecas/1493/large/fanaticosrionoteatro.png -> 200
• GET /arquivos/pecas/1342/large/lisa-lesa-e-loucarionoteatro.png -> 200
• 2026-04-08 03:35:35 -03
• GET com range parcial nas 3 imagens -> 206
• isso indica que:
• a Meta já conseguiu baixar as 3 imagens
• HEAD/GET/Range não parecem ser a falha principal neste momento

Evidência nova do bloqueio residual

• o mesmo log mostra outro crawler da Meta tomando bloqueio no site:
• 2026-04-08 03:31:02 -03
• GET /areninha-cultural-municipal-jacob-do-bandolim -> 403
• user-agent:
• meta-externalads/1.1 (+https://developers.facebook.com/docs/sharing/webmasters/crawler)
• esse user-agent não está coberto explicitamente no allowlist atual do access_by_lua_block
• leitura operacional:
• as imagens do feed estão liberadas por path e já responderam bem
• mas parte do ecossistema de crawlers da Meta ainda está sendo barrada pelo geoblock em outras URLs públicas

Hipótese mais forte atual

• o erro visto no Commerce Manager pode estar:
• em cache/estado antigo do processamento automático feito antes do ajuste
• ou em uma validação paralela da Meta usando outro crawler/rota pública além da imagem, com user-agent ainda bloqueado
• isso explicaria a combinação:
• imagem com 200/206 no log
• interface da Meta ainda acusando erro

Itens descartados nesta sessão

• URL de image_link com caractere estranho ou encoding quebrado
• arquivo inexistente
• permissão/owner incorretos
• content-type errado
• PNG quebrado ou formato inválido básico
• problema de certificado/SAN para rionoteatro.com.br

Leitura externa das páginas da Meta

• worker gemini conseguiu sintetizar as páginas de ajuda focando no caso do catálogo
• pontos úteis extraídos:
• a imagem precisa ser pública, sem login, sem cookie e sem proteção por senha
• a Meta costuma usar user-agents como facebookexternalhit e Facebot
• bloqueios por firewall, WAF, geo, robots.txt, auth, redirect e SSL quebram o fetch
• retornos 403, 401, 404 e cadeias de redirecionamento são causas clássicas
• o cabeçalho precisa responder como imagem (image/png, image/jpeg etc.)
• a Meta recomenda testar a URL crua e usar o debugger deles para inspecionar o fetch
• worker opencode não conseguiu abrir diretamente essas URLs da Meta nesta sessão:
• webfetch failed
• Request failed with status code: 400

Leitura operacional atual

• hipótese mais forte:
• o geoblock por país da VPS estava bloqueando o crawler da Meta nas URLs públicas das imagens
• hipótese secundária:
• algum fetch da Meta pode ter usado user-agent/origem diferente do bypass anterior e por isso a exceção por path ficou mais segura

Próximo passo

• aguardar novo processamento da Meta após a exceção por path no Nginx
• confirmar se os 3 problemas de imagem desaparecem
• se desaparecerem, fechar o BK-230 com a causa raiz documentada como geoblock por país

Estado atual para retomada em 2026-04-08

• feed principal de teste publicado em:
• https://rionoteatro.com.br/pecas_042026.xml
• alias legado mantido em:
• https://rionoteatro.com.br/pecas.xml
• o gerador foi ajustado para gravar os dois arquivos com o mesmo conteúdo
• o retorno do botão manual no admin passou a expor a nova URL principal

Validações finais desta noite

• curl -I -A "facebookexternalhit/1.1" https://rionoteatro.com.br/pecas.xml -> 200
• curl -I -A "Meta-ExternalAgent/1.1" https://rionoteatro.com.br/pecas.xml -> 200
• curl -I -A "facebookexternalhit/1.1" https://rionoteatro.com.br/arquivos/pecas/1341/large/o-otimismo-que-faz-o-besouro-voarrionoteatro.png -> 200
• curl -I -A "meta-externalads/1.1" https://rionoteatro.com.br/arquivos/pecas/1341/large/o-otimismo-que-faz-o-besouro-voarrionoteatro.png -> 200
• curl -I -L https://rionoteatro.com.br/pecas_042026.xml -> 200
• dig rionoteatro.com.br mostrou resolução direta para:
• 72.60.252.173
• leitura operacional:
• sem Cloudflare na frente
• no estado atual do servidor, XML e imagem estão acessíveis para os user-agents testados da Meta

Geoblock no estado atual

• para isolar o problema, o bloco access_by_lua_block do vhost foi totalmente comentado para teste
• arquivo afetado:
• /www/server/panel/vhost/nginx/rionoteatro.com.br.conf
• backup da configuração antes dessa desativação:
• /www/server/panel/vhost/nginx/rionoteatro.com.br.conf.bak.2026-04-08-0412
• isso deixa a rodada atual em modo de teste sem geoblock do domínio

Observações relevantes da rodada

• houve requests antigos em log para:
• /pecas_042026.xml -> 404
• /pecas_042026.xml.xml -> 404
• esses eventos ocorreram antes do feed novo estar corretamente publicado e não provam bloqueio atual
• a interface do Commerce Manager ficou por bastante tempo em:
• Aplicando novas regras do feed...
• leitura operacional:
• isso parece mais estado pendente/cache da Meta do que erro atual evidente do nosso endpoint

Janela de retomada

• próxima atualização automática mostrada na Meta:
• 2026-04-08 10:15 -03
• decisão operacional desta noite:
• deixar a Meta atualizar sozinha
• retestar amanhã após essa janela

Próximo passo objetivo para amanhã

• verificar o resultado da atualização automática da Meta após 2026-04-08 10:15 -03
• se os erros sumirem:
• concluir que a proteção/geoblock era o fator principal
• se os erros persistirem mesmo sem geoblock e com 200 no XML/imagens:
• considerar estado preso/cache da Meta
• considerar recriar a fonte de dados apontando para pecas_042026.xml
• considerar cache-bust por nome novo de imagem em item de teste

HANDOFF - Estado em 08/04/2026 (tomada de decisão amanhã)

Feed:

• pecas_042026.xml gerado e publicado
• pecas.xml como alias (aponta para o mesmo conteúdo)

Validações HTTP 200:

• XML: pecas.xml, pecas_inteira.xml, pecas_042026.xml
• Imagens: /arquivos/pecas//large/
• User-agents: facebookexternalhit, meta-externalads ✅

Infraestrutura:

• Cloudflare: ❌ (não utilizado)
• Geoblock Nginx: ⚠️ comentado temporariamente para teste

Meta Commerce Manager:

• Status: Travado em "Aplicando novas regras do feed..."
• Última execução detectada: 03:35 (3 imagens → 206)

Próximo passo amanhã:

• Reenviar feed no Meta Business Manager
• Verificar se erro de imagem desaparece no processamento

Fechamento posterior

Atualizado em: 2026-04-09 22:08 -03

• o Facebook voltou a aceitar o feed canônico pecas.xml;
• auditoria do código vivo confirmou que:
• atualizar_feed.php grava pecas.xml e pecas_inteira.xml;
• admin/modulos/pecas/action.php voltou a expor pecas.xml como URL principal;
• não há mais geração ativa de pecas_042026.xml no código do projeto;
• leitura operacional consolidada:
• pecas_042026.xml era apenas artefato temporário de mitigação;
• o problema principal era compatível com o bloqueio de geo IP/crawlers da Meta;
• US e IE não devem entrar em bloqueio bruto que afete o fetch do catálogo.

Estado final desta trilha

• pecas.xml volta a ser o feed canônico do catálogo;
• pecas_042026.xml pode ser removido sem alterar o gerador;
• o próximo follow-up, se necessário, passa a ser apenas endurecer a política de geo IP sem quebrar crawlers relevantes.