Eu tenho uma configuração única e interessante do que eu posso dizer, com um problema interessante. Eu tenho uma caixa do Windows Server 2012 como o meu principal servidor web hosting website.com. No link , eu tenho uma configuração de proxy reverso com ARR para apontar tudo de volta para uma instalação do Wordpress WPMU em uma caixa do Debian executando o Apache. Aqui está a configuração da regra de reescrita:
Agora,tudofuncionacorretamente,masaúnicacoisaqueatrapalhaéqueseeuforaqualquerpáginawp-admin/atravésdoproxyreverso,receboumloopderedirecionamento:
Paraserprecisocomoqueestoudescrevendo,aquiestáomeu
O que eu acho interessante é que, se eu mudar meu arquivo de hosts locais para apontar meu domínio para o endereço IP do Debian e ignorar a ARR do IIS, então o wp-admin / funciona bem, sem problemas. Parece que o meu problema está em algum lugar com a tradução entre o IIS e o Apache? Eu estou em uma perda para o que olhar e depurar isso mais.
Qualquer ajuda seria muito apreciada!
Possivelmente isso acontece porque o cabeçalho Host é modificado pela ARR.
GET http://10.48.100.27/ HTTP/1.1
Host: 10.48.100.27
HTTP/1.1 301 Moved Permanently
Location: http://example.com/
Use a configuração preserveHeadHeader para manter o cabeçalho inalterado.
Eu estou querendo saber se o regex está ficando confuso com o mecanismo de reescrita do apache. Você tentou desativar o arquivo .htaccess e visitar o arquivo real em "... / wp-admin /" como "... / wp-admin / admin.php" em vez disso?
A metodologia para resolver isso incluiria a identificação do problema real.
Desativaria temporariamente https para o site de administração, em uma rede de teste ou de teste, se necessário, devido a requisitos de segurança.
Em seguida, eu detectaria o tráfego relevante do host do IIS / ARR ou do host do Apache, para ver o que de fato acontece entre os hosts quando você chama a página de administração. Controlar despejos para o tráfego entre o cliente e o IIS, bem como o cliente, e o Apache provavelmente ajuda também. Use seu sniffer favorito, então deixe-me sugerir Wireshark para Windows ou tcpdump para Linux.
Tenho certeza de que você veria rapidamente se há um problema de redirecionamento, um problema de interpretação da url regex ou outra coisa. A solução, é claro, dependeria do que você realmente acha.
Esta é a melhor maneira que conheço de depurar as estranhezas do proxy reverso, já que se trabalha com fatos que diminuem o escopo do problema em vez de especulações que o ampliam.
Para obter ajuda com a análise, eu colocaria dois despejos de pacotes filtrados: um para passar pelo proxy reverso do IIS e outro para conectar-se diretamente ao Apache, diferenças destacadas.