Hospedar o ASP.NET Core no Linux com o Apache

Por Shayne Boyer

Usando este guia, aprenda como configurar o Apache como um servidor proxy reverso no CentOS 7 para redirecionar o tráfego HTTP para um aplicativo Web ASP.NET Core em execução no servidor Kestrel. A extensão mod_proxy e os módulos relacionados criam o proxy reverso do servidor.

Cuidado

Este artigo faz referência ao CentOS, uma distribuição do Linux que está se aproximando do status de EOL (Fim da Vida Útil). Considere seu uso e planeje adequadamente. Para obter mais informações, veja as Diretrizes sobre fim da vida útil do CentOS.

Pré-requisitos

• Servidor que executa o CentOS 7 com uma conta de usuário padrão com privilégio sudo.
• Instale o runtime do .NET Core no servidor.
  1. Acesse a página Baixar o .NET Core.
  2. Selecione a versão mais recente não prévia do .NET Core.
  3. Baixe o runtime não visualizado mais recente na tabela em Executar aplicativos – Runtime.
  4. Selecione o link Instruções do gerenciador de pacotes do Linux e siga as instruções do CentOS.
• Um aplicativo ASP.NET Core existente.

A qualquer momento no futuro, depois de atualizar a estrutura compartilhada, reinicie os aplicativos ASP.NET Core hospedados pelo servidor.

Publicar e copiar o aplicativo

Configurar o aplicativo para um implantação dependente de estrutura.

Se o aplicativo for executado localmente no Ambiente de desenvolvimento e não estiver configurado pelo servidor para fazer conexões HTTPS seguras, adote uma das seguintes abordagens:

• Configure o aplicativo para lidar com conexões seguras locais. Para obter mais informações, veja a seção Configuração de HTTPS.

• Configure o aplicativo para ser executado no ponto de extremidade inseguro:

  • Desativar o middleware de redirecionamento HTTPS no ambiente de desenvolvimento (Program.cs):

    if (!app.Environment.IsDevelopment())
    {
        app.UseHttpsRedirection();
    }
    

    Para obter mais informações, confira Usar vários ambientes no ASP.NET Core.

  • Remova https://localhost:5001 (se houver) da propriedade applicationUrl no arquivo Properties/launchSettings.json.

Para obter mais informações sobre a configuração por ambiente, consulte Use vários ambientes no ASP.NET Core.

Execute dotnet publish do ambiente de desenvolvimento para empacotar um aplicativo em um diretório (por exemplo, bin/Release/{TARGET FRAMEWORK MONIKER}/publish, onde o espaço reservado {TARGET FRAMEWORK MONIKER} é o TFM (Moniker da Estrutura de Destino)) que pode ser executado no servidor:

dotnet publish --configuration Release

O aplicativo também poderá ser publicado como uma implantação autossuficiente se você preferir não manter o runtime do .NET Core no servidor.

Copie o aplicativo ASP.NET Core para o servidor usando uma ferramenta que se integre ao fluxo de trabalho da organização (por exemplo, SCP, SFTP). É comum para localizar os aplicativos Web no diretório var (por exemplo, var/www/helloapp).

Observação

Em um cenário de implantação de produção, um fluxo de trabalho de integração contínua faz o trabalho de publicar o aplicativo e copiar os ativos para o servidor.

Configurar um servidor proxy

Um proxy reverso é uma configuração comum para atender a aplicativos Web dinâmicos. O proxy reverso encerra a solicitação HTTP e a encaminha para o aplicativo ASP.NET.

Um servidor proxy encaminha as solicitações de cliente para outro servidor, em vez de atendê-las por conta própria. Um proxy reverso encaminha para um destino fixo, normalmente, em nome de clientes arbitrários. Neste guia, o Apache é configurado como o proxy reverso em execução no mesmo servidor em que o Kestrel está servindo o aplicativo ASP.NET Core.

Uma vez que as solicitações são encaminhadas pelo proxy reverso, use o Middleware de Cabeçalhos Encaminhados do pacote Microsoft.AspNetCore.HttpOverrides. O middleware atualiza o Request.Scheme usando o cabeçalho X-Forwarded-Proto, de forma que URIs de redirecionamento e outras políticas de segurança funcionam corretamente.

Qualquer componente que dependa do esquema, como autenticação, geração de link, redirecionamentos e localização geográfica, deverá ser colocado depois de invocar o Middleware de Cabeçalhos Encaminhados.

Middlewares de Cabeçalhos Encaminhados devem ser executados antes de outros middlewares. Essa ordenação garantirá que o middleware conte com informações de cabeçalhos encaminhadas que podem consumir os valores de cabeçalho para processamento. Para executar o Middleware de Cabeçalhos Encaminhados após o diagnóstico e o middleware de tratamento de erros, consulte Ordem do Middleware de Cabeçalhos Encaminhados.

Invocar o método UseForwardedHeaders na parte superior de Startup.Configure antes de chamar outro middleware. Configure o middleware para encaminhar os cabeçalhos X-Forwarded-For e X-Forwarded-Proto.

Adicione o namespace Microsoft.AspNetCore.HttpOverrides à parte superior do arquivo:

using Microsoft.AspNetCore.HttpOverrides;

No pipeline de processamento do aplicativo:

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});

app.UseAuthentication();

Se nenhum ForwardedHeadersOptions for especificado para o middleware, os cabeçalhos padrão para encaminhar serão None.

Os proxies em execução em endereços de loopback (127.0.0.0/8, [::1]), incluindo o endereço de host local padrão (127.0.0.1), são confiáveis por padrão. Se outros proxies ou redes confiáveis em que a organização trata solicitações entre a Internet e o servidor Web, adicione-os à lista de KnownProxies ou KnownNetworks com ForwardedHeadersOptions. O exemplo a seguir adiciona um servidor proxy confiável no endereço IP 10.0.0.100 ao Middleware de cabeçalhos encaminhados KnownProxies em Startup.ConfigureServices:

Adicione o namespace System.Net à parte superior do arquivo:

using System.Net;

Use o seguinte registro de serviço:

services.Configure<ForwardedHeadersOptions>(options =>
{
    options.KnownProxies.Add(IPAddress.Parse("10.0.0.100"));
});

Para obter mais informações, veja Configurar o ASP.NET Core para trabalhar com servidores proxy e balanceadores de carga.

Instalar o Apache

Atualize os pacotes CentOS para as respectivas versões estáveis mais recentes:

sudo yum update -y

Instale o servidor Web do Apache no CentOS com um único comando yum:

sudo yum -y install httpd mod_ssl

Saída de exemplo depois de executar o comando:

Downloading packages:
httpd-2.4.6-40.el7.centos.4.x86_64.rpm               | 2.7 MB  00:00:01
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : httpd-2.4.6-40.el7.centos.4.x86_64      1/1 
Verifying  : httpd-2.4.6-40.el7.centos.4.x86_64      1/1 

Installed:
httpd.x86_64 0:2.4.6-40.el7.centos.4

Complete!

Observação

Neste exemplo, o resultado reflete httpd.86_64, pois a versão do CentOS 7 é de 64 bits. Para verificar o local em que o Apache está instalado, execute whereis httpd em um prompt de comando.

Configurar o Apache

Os arquivos de configuração do Apache estão localizados no diretório /etc/httpd/conf.d/. No Apache no Ubuntu, todos os arquivos de configuração de host virtual são armazenados no /etc/apache2/sites-available. Qualquer arquivo com a extensão .conf é processado em ordem alfabética, além dos arquivos de configuração do módulo em /etc/httpd/conf.modules.d/, que contém todos os arquivos de configuração necessários para carregar os módulos.

Crie um arquivo de configuração chamado helloapp.conf para o aplicativo:

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}s
</VirtualHost>

<VirtualHost *:80>
    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:5000/
    ProxyPassReverse / http://127.0.0.1:5000/
    ServerName www.example.com
    ServerAlias *.example.com
    ErrorLog ${APACHE_LOG_DIR}/helloapp-error.log
    CustomLog ${APACHE_LOG_DIR}/helloapp-access.log common
</VirtualHost>

Nota: as versões do Apache anteriores a 2.4.6 não exigem o RequestHeader setcontêm o final s:

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
</VirtualHost>

Para obter mais informações, veja %{VARNAME}s in Módulo Apache mod_headers.

O bloco VirtualHost pode aparecer várias vezes, em um ou mais arquivos em um servidor. No arquivo de configuração anterior, o Apache aceita tráfego público na porta 80. O domínio www.example.com está sendo atendido e o alias *.example.com é resolvido para o mesmo site. Para obter mais informações, confira Suporte a host virtual baseado em nome. As solicitações passadas por proxy na raiz para a porta 5000 do servidor em 127.0.0.1. Para a comunicação bidirecional, ProxyPass e ProxyPassReverse são necessários. Para alterar o IP/porta do Kestrel, veja Kestrel: configuração de ponto de extremidade.

Aviso

Falha ao especificar uma diretiva ServerName no bloco VirtualHost expõe seu aplicativo para vulnerabilidades de segurança. Associações de curinga de subdomínio (por exemplo, *.example.com) não oferecerão esse risco de segurança se você controlar o domínio pai completo (em vez de *.com, o qual é vulnerável). Para obter mais informações, consulte RFC 9110: Semântica HTTP (Seção 7.2: Host e :authority).

O registro em log pode ser configurado por VirtualHost usando diretivas ErrorLog e CustomLog. ErrorLog é o local em que o servidor registrará em log os erros, enquanto CustomLog define o nome de arquivo e o formato do arquivo de log. Nesse caso, esse é o local em que as informações de solicitação são registradas em log. Há uma linha para cada solicitação.

Salve o arquivo e teste a configuração. Se tudo passar, a resposta deverá ser Syntax [OK].

sudo apachectl configtest

Reinicie o Apache:

sudo systemctl restart httpd
sudo systemctl enable httpd

Para obter mais informações sobre valores de diretiva de cabeçalho, veja Mod_headers do módulo Apache.

Monitorar o aplicativo

O Apache agora está configurado para encaminhar solicitações feitas a http://localhost:80 para o aplicativo ASP.NET Core em execução no Kestrel em http://127.0.0.1:5000. No entanto, o Apache não está configurado para gerenciar o processo Kestrel. Use systemd e crie um arquivo de serviço para iniciar e monitorar o aplicativo Web subjacente. systemd é um sistema de inicialização que fornece muitos recursos poderosos para iniciar, parar e gerenciar processos.

Criar o arquivo de serviço

Crie o arquivo de definição de serviço:

sudo nano /etc/systemd/system/kestrel-helloapp.service

Eis um exemplo de arquivo de serviço para o aplicativo:

[Unit]
Description=Example .NET Web API App running on CentOS 7

[Service]
WorkingDirectory=/var/www/helloapp
ExecStart=/usr/local/bin/dotnet /var/www/helloapp/helloapp.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=dotnet-example
User=apache
Environment=ASPNETCORE_ENVIRONMENT=Production 

[Install]
WantedBy=multi-user.target

Observação: defina a pasta local/bin para sua distribuição. Algumas versões do Ubuntu exigem ExecStart=/usr/bin/dotnet

No exemplo anterior, o usuário que gerencia o serviço é especificado pela opção User. O usuário (apache) deve existir e ter a propriedade adequada dos arquivos do aplicativo.

Use TimeoutStopSec para configurar a duração do tempo de espera para o aplicativo desligar depois de receber o sinal de interrupção inicial. Se o aplicativo não desligar nesse período, o SIGKILL será emitido para encerrá-lo. Forneça o valor como segundos sem unidade (por exemplo, 150), um valor de duração (por exemplo, 2min 30s) ou infinity para desabilitar o tempo limite. TimeoutStopSec é revertido para o valor padrão de DefaultTimeoutStopSec no arquivo de configuração do gerenciador (systemd-system.conf, system.conf.d, systemd-user.conf e user.conf.d). O tempo limite padrão para a maioria das distribuições é de 90 segundos.

# The default value is 90 seconds for most distributions.
TimeoutStopSec=90

Alguns valores (por exemplo, cadeias de conexão de SQL) devem ser escapadas para que os provedores de configuração leiam as variáveis de ambiente. Use o seguinte comando para gerar um valor corretamente com caracteres de escape para uso no arquivo de configuração:

systemd-escape "<value-to-escape>"

Separadores do tipo dois-pontos (:) não são compatíveis com nomes de variáveis de ambiente. Use um sublinhado duplo (__) no lugar de dois-pontos. O provedor de configuração de Variáveis de Ambiente converte caracteres de sublinhado duplo em dois-pontos quando as variáveis de ambiente são lidas na configuração. No exemplo a seguir, a chave de cadeia de conexão ConnectionStrings:DefaultConnection está definida no arquivo de definição de serviço como ConnectionStrings__DefaultConnection:

Environment=ConnectionStrings__DefaultConnection={Connection String}

Salve o arquivo e habilite o serviço:

sudo systemctl enable kestrel-helloapp.service

Inicie o serviço e verifique se ele está em execução:

sudo systemctl start kestrel-helloapp.service
sudo systemctl status kestrel-helloapp.service

◝ kestrel-helloapp.service - Example .NET Web API App running on CentOS 7
    Loaded: loaded (/etc/systemd/system/kestrel-helloapp.service; enabled)
    Active: active (running) since Thu 2016-10-18 04:09:35 NZDT; 35s ago
Main PID: 9021 (dotnet)
    CGroup: /system.slice/kestrel-helloapp.service
            └─9021 /usr/local/bin/dotnet /var/www/helloapp/helloapp.dll

Com o proxy reverso configurado e o Kestrel gerenciado por meio de systemd, o aplicativo Web está totalmente configurado e pode ser acessado em um navegador no computador local em http://localhost. Inspecionando os cabeçalhos de resposta, o cabeçalho Server indica que o aplicativo ASP.NET Core é servido pelo Kestrel:

HTTP/1.1 200 OK
Date: Tue, 11 Oct 2016 16:22:23 GMT
Server: Kestrel
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked

Exibir logs

Já que o aplicativo Web usando Kestrel é gerenciado usando systemd, os eventos e os processos são registrados em um diário centralizado. No entanto, esse diário contém todas as entradas para todos os serviços e processos gerenciados por systemd. Para exibir os itens específicos de kestrel-helloapp.service, use o seguinte comando:

sudo journalctl -fu kestrel-helloapp.service

Para filtragem de hora, especifique opções de tempo com o comando. Por exemplo, use --since today para filtrar o dia atual ou --until 1 hour ago para ver as entradas da hora anterior. Para obter mais informações, confira a página de manual para journalctl.

sudo journalctl -fu kestrel-helloapp.service --since "2016-10-18" --until "2016-10-18 04:00"

Proteção de dados

A pilha de proteção de dados do ASP.NET Core é usada por vários middlewares do ASP.NET Core, incluindo o middleware de autenticação (por exemplo, o middleware de cookie) e as proteções de CSRF (solicitação intersite forjada). Mesmo se as APIs de Proteção de Dados não forem chamadas pelo código do usuário, a proteção de dados deverá ser configurada para criar um repositório de chaves criptográfico persistente. Se a proteção de dados não estiver configurada, as chaves serão mantidas na memória e descartadas quando o aplicativo for reiniciado.

Se o token de autenticação for armazenado na memória quando o aplicativo for reiniciado:

• Todos os tokens de autenticação baseados em cookie serão invalidados.
• Os usuários precisam entrar novamente na próxima solicitação deles.
• Todos os dados protegidos com o token de autenticação não poderão mais ser descriptografados. Isso pode incluir os tokens CSRF e cookies TempData do MVC do ASP.NET Core.

Para configurar a proteção de dados de modo que ela mantenha e criptografe o token de autenticação, consulte:

• Provedores de armazenamento de chaves no ASP.NET Core
• Criptografia de chave em repouso no Windows e no Azure usando o ASP.NET Core

Proteger o aplicativo

Configurar o firewall

Firewalld é um daemon dinâmico para gerenciar o firewall com suporte para zonas de rede. Portas e filtragem de pacote ainda podem ser gerenciados pelo iptables. Firewalld deve ser instalado por padrão. yum pode ser usado para instalar o pacote ou verificar se ele está instalado.

sudo yum install firewalld -y

Use firewalld para abrir somente as portas necessárias para o aplicativo. Nesse caso, as portas 80 e 443 são usadas. Os comandos a seguir definem permanentemente as portas 80 e 443 para estarem abertas:

sudo firewall-cmd --add-port=80/tcp --permanent
sudo firewall-cmd --add-port=443/tcp --permanent

Recarregue as configurações de firewall. Verifique os serviços e as portas disponíveis na zona padrão. As opções estão disponíveis por meio da inspeção de firewall-cmd -h.

sudo firewall-cmd --reload
sudo firewall-cmd --list-all

public (default, active)
interfaces: eth0
sources: 
services: dhcpv6-client
ports: 443/tcp 80/tcp
masquerade: no
forward-ports: 
icmp-blocks: 
rich rules: 

Configuração de HTTPS

Configurar o aplicativo para conexões seguras (HTTPS) locais

O comando dotnet run usa o arquivo Properties/launchSettings.json do aplicativo, que configura o aplicativo para escutar nas URLs fornecidas pela propriedade applicationUrl (por exemplo, https://localhost:5001;http://localhost:5000).

Configure o aplicativo para usar um certificado no desenvolvimento para o comando dotnet run ou no ambiente de desenvolvimento (F5 ou Ctrl + F5 no Visual Studio Code) usando uma das seguintes abordagens:

• Substituir o certificado padrão da configuração (Recomendado)
• KestrelServerOptions.ConfigureHttpsDefaults

Configurar o proxy reverso para conexões de cliente seguras (HTTPS)

Aviso

A configuração de segurança nesta seção é uma configuração geral a ser usada como ponto de partida para personalização adicional. Não é possível fornecer suporte para ferramentas, servidores e sistemas operacionais de terceiros. Use a configuração nesta seção por sua conta e risco. Para obter mais informações, acesse os seguintes recursos:

• Criptografia SSL/TLS do Apache (documentação do Apache)
• Gerador de configuração SSL mozilla.org

Para configurar o Apache para HTTPS, o módulo mod_ssl é usado. Quando o módulo httpd foi instalado, o módulo mod_ssl também foi instalado. Se ele não foi instalado, use yum para adicioná-lo à configuração.

sudo yum install mod_ssl

Para impor o HTTPS, instale o módulo mod_rewrite para habilitar a regravação de URL:

sudo yum install mod_rewrite

Modifique o arquivo helloapp.conf para habilitar a comunicação segura na porta 443.

O exemplo a seguir não configura o servidor para redirecionar solicitações inseguras. É recomendável usar o Middleware de Redirecionamento HTTPS. Para obter mais informações, confira Impor HTTPS no ASP.NET Core.

Observação

Para ambientes de desenvolvimento em que a configuração do servidor manipula o redirecionamento seguro em vez do Middleware de Redirecionamento HTTPS, recomendamos usar redirecionamentos temporários (302) em vez de permanentes (301). O cache de link pode causar um comportamento instável em ambientes de desenvolvimento.

A adição de um cabeçalho Strict-Transport-Security (HSTS) garante que todas as próximas solicitações feitas pelo cliente sejam por HTTPS. Para obter diretrizes sobre como definir o Strict-Transport-Security cabeçalho, confira Impor HTTPS em ASP.NET Core.

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
</VirtualHost>

<VirtualHost *:443>
    Protocols             h2 http/1.1
    ProxyPreserveHost     On
    ProxyPass             / http://127.0.0.1:5000/
    ProxyPassReverse      / http://127.0.0.1:5000/
    ErrorLog              /var/log/httpd/helloapp-error.log
    CustomLog             /var/log/httpd/helloapp-access.log common
    SSLEngine             on
    SSLProtocol           all -SSLv3 -TLSv1 -TLSv1.1
    SSLHonorCipherOrder   off
    SSLCompression        off
    SSLSessionTickets     on
    SSLUseStapling        off
    SSLCertificateFile    /etc/pki/tls/certs/localhost.crt
    SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
    SSLCipherSuite        ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
</VirtualHost>

Observação

Este exemplo usa um certificado gerado localmente. SSLCertificateFile deve ser o arquivo de certificado primário para o nome de domínio. SSLCertificateKeyFile deve ser o arquivo de chave gerado quando o CSR é criado. SSLCertificateChainFile deve ser o arquivo de certificado intermediário (se houver) fornecido pela autoridade de certificação.

O Apache HTTP Server versão 2.4.43 ou mais recente é necessário para operar um servidor Web TLS 1.3 com OpenSSL 1.1.1.

Observação

O exemplo anterior desabilita a associação do protocolo OCSP. Para obter mais informações e diretrizes sobre como habilitar o OCSP, consulte Associação do OCSP (documentação do Apache).

Salve o arquivo e teste a configuração:

sudo service httpd configtest

Reinicie o Apache:

sudo systemctl restart httpd

Sugestões adicionais do Apache

Reiniciar aplicativos com atualizações de estrutura compartilhada

Depois de atualizar a estrutura compartilhada no servidor, reinicie os aplicativos ASP.NET Core hospedados pelo servidor.

Cabeçalhos adicionais

Para proteção contra ataques mal-intencionados, há alguns cabeçalhos que devem ser modificados ou adicionados. Verifique se o módulo mod_headers está instalado:

sudo yum install mod_headers

Proteger o Apache contra ataques de clickjacking

Clickjacking, também conhecido como um ataque por inferência na interface do usuário, é um ataque mal-intencionado em que o visitante do site é levado a clicar em um link ou botão em uma página diferente daquela que está visitando atualmente. Use X-FRAME-OPTIONS para proteger o site.

Para atenuar ataques de clickjacking:

1. Edite o arquivo httpd.conf:

   sudo nano /etc/httpd/conf/httpd.conf
   

   Adicione a linha Header append X-FRAME-OPTIONS "SAMEORIGIN".

2. Salve o arquivo.

3. Reinicie o Apache.

Detecção de tipo MIME

O cabeçalho X-Content-Type-Options impedirá o Internet Explorer de farejar por MIME (determinar o Content-Type de um arquivo com base no conteúdo do arquivo). Se o servidor define o cabeçalho Content-Type para text/html com a opção nosniff definida, o Internet Explorer renderiza o conteúdo como text/html, independentemente do conteúdo do arquivo.

Edite o arquivo httpd.conf:

sudo nano /etc/httpd/conf/httpd.conf

Adicione a linha Header set X-Content-Type-Options "nosniff". Salve o arquivo. Reinicie o Apache.

Balanceamento de carga

Este exemplo mostra como instalar e configurar o Apache no CentOS 7 e Kestrel no mesmo computador da instância. Para não ter um ponto único de falha, o uso de mod_proxy_balancer e a modificação do VirtualHost permitiriam o gerenciamento de várias instâncias dos aplicativos Web protegidos pelo servidor proxy do Apache.

sudo yum install mod_proxy_balancer

No arquivo de configuração mostrado abaixo, uma instância adicional do helloapp é configurada para ser executada na porta 5001. A seção Proxy é definida com uma configuração de balanceador com dois membros para balancear carga de byrequests.

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
</VirtualHost>

<VirtualHost *:80>
    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
</VirtualHost>

<VirtualHost *:443>
    ProxyPass / balancer://mycluster/ 

    ProxyPassReverse / http://127.0.0.1:5000/
    ProxyPassReverse / http://127.0.0.1:5001/

    <Proxy balancer://mycluster>
        BalancerMember http://127.0.0.1:5000
        BalancerMember http://127.0.0.1:5001 
        ProxySet lbmethod=byrequests
    </Proxy>

    <Location />
        SetHandler balancer
    </Location>
    ErrorLog /var/log/httpd/helloapp-error.log
    CustomLog /var/log/httpd/helloapp-access.log common
    SSLEngine on
    SSLProtocol all -SSLv2
    SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:!RC4+RSA:+HIGH:+MEDIUM:!LOW:!RC4
    SSLCertificateFile /etc/pki/tls/certs/localhost.crt
    SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
</VirtualHost>

Limites de taxa

Usando mod_ratelimit, que está incluído no módulo httpd, a largura de banda de clientes pode ser limitada:

sudo nano /etc/httpd/conf.d/ratelimit.conf

O arquivo de exemplo limita a largura de banda a 600 KB/s no local raiz:

<IfModule mod_ratelimit.c>
    <Location />
        SetOutputFilter RATE_LIMIT
        SetEnv rate-limit 600
    </Location>
</IfModule>

Campos de cabeçalho da solicitação muito grandes

As configurações padrão do servidor proxy normalmente limitam os campos de cabeçalho de solicitação a 8.190 bytes. Um aplicativo pode exigir campos maiores que o padrão (por exemplo, aplicativos que utilizam o Microsoft Entra ID). Se forem necessários campos mais longos, a diretiva LimitRequestFieldSize do servidor proxy exigirá ajuste. O valor a ser aplicado depende do cenário. Para obter mais informações, confira a documentação do servidor.

Aviso

Não aumente o valor padrão de LimitRequestFieldSize a menos que necessário. Aumentar esse valor aumenta o risco de estouro de buffer (estouro) e ataques de DoS (negação de serviço) por usuários mal-intencionados.

Recursos adicionais

• Pré-requisitos para o .NET Core no Linux
• Solucionar problemas e depurar projetos do ASP.NET Core
• Configurar o ASP.NET Core para trabalhar com servidores proxy e balanceadores de carga