Я полагаю, что понял это, и я просто был идиотом.
Из-за ошибки, которая произошла на прошлой неделе (который был с тех пор зафиксирован), было время, когда один zip-файл мог быть изменен двумя процессами, которые оба пытались добавить в тот же файл. Так, я полагаю, что из-за некоторой zipfile проблемы параллелизма, когда оба процесса были сделаны, это имело эффект двух zip-файлов, связанных вместе. И, оказывается, что различные инструменты разархивации посмотрят на различные части этого монстра Franken-zip. Так, в то время как я использовал, разархивировали на сервере или после использования wget, который посмотрел на одну часть zip-файла, и в то время как я использовал инструмент OSX GUI по умолчанию для разархивации, который посмотрел на другую часть zip-файла.
Загрузка одного .zip файла и использование двух отдельных инструментов проверяют эту теорию.
Извините, что проблема не была об апаче, как я первоначально думал.
Я делал это сложнее, чем нужно.
Я изменил свой nginx.conf следующим образом:
server {
listen 80;
server_name example.com;
root /var/www;
location = /lvs.htm {
#do nothing
}
location / {
return 301 https://example.com$request_uri;
}
}
lvs.htm находится в / var / www, поэтому местоположение совпадает, поиск прекращается и lvs.htm обслуживается с кодом ответа 200. LVS добавляет сервер в пул, и при его попадании nginx правильно перенаправляет на https с 301.