Os comentários de @ Michael-Hampton deram a resposta para a pergunta que eu fiz. Sugeri há cerca de 6 semanas que, se ele postasse essa informação como resposta, eu a marcaria como aceita. Mas desde que ele não fez isso, estou construindo uma resposta aqui para aceitar. Parece uma pena deixar isso sem resposta.
A resposta à pergunta, como eu perguntei, é que a configuração nginx que eu especifiquei forçou all solicitações para primeiro tentar veicular a página estática site-down.html . E como as imagens foram especificadas como URLs para o mesmo site, essas solicitações de imagem também foram manipuladas pela diretiva / location , portanto, o try_files foi aplicado e alterado também para exibir a página site-down.html .
Eu não sei por que as imagens apareceram depois de algumas recargas e espera, algo deve ter expirado.
A maneira mais direta de resolver o problema, como eu estava vendo, foi alterar o URL da imagem de plano de fundo em data url com o próprio conteúdo da imagem incorporado em base64 strings. Ao fazer isso, a página site-down.html não gera solicitações adicionais de recursos e funciona como pretendi originalmente.
Mas ele também observou que o que eu estou tentando fazer, ao trabalhar, dá um código de status 200, embora o site esteja basicamente inativo. Expliquei que o site é destinado apenas a usuários interativos, não a servidores, e isso é para interrupções intencionais de curto prazo, não para erros como uma falha de servidor de back-end. Então eu não vejo isso como um grande problema. Mas a verdade é que é sempre melhor dar um código de status significativo. Então eu acho que a solução "certa" para mim é ter dois arquivos de configuração nginx "disponíveis" diferentes, um dos quais simplesmente codifica uma resposta 503 usando site-down.html como uma página de erro personalizada. Então, ao invés de criar / remover um link simbólico chamado site-down.html na raiz, e confiar em try_files para dar o comportamento desejado, eu deveria apenas mudar o symlink no diretório habilitado para sites para selecionar a configuração correta e fazer um sudo service nginx reload para alternar suavemente comportamentos.
A vantagem de usar try_files é que o comportamento muda imediatamente com um comando, enquanto a desvantagem é que o código de status indica que o site está funcionando bem, embora não esteja. A vantagem de trocar arquivos de configuração é que ele fornece um status significativo, enquanto a desvantagem é que a etapa extra de recarregar o nginx é algo que pode ser esquecido. No entanto, no final, o switch será feito por um script e o script não esquecerá de recarregar a configuração.