Incapaz de ler os dados da conexão de transporte: uma conexão existente foi fechada à força pelo host remoto

Tenho um aplicativo de servidor e às vezes, quando o cliente tenta se conectar, recebo o seguinte erro:

NOTA: o "não foi possível obter o stream do cliente ou o login falhou" é um texto adicionado por mim na instrução catch

e a linha na qual ele para (sThread: linha 96) é:

tcpClient = (TcpClient)client;
clientStream = tcpClient.GetStream();
sr = new StreamReader(clientStream);
sw = new StreamWriter(clientStream);

// line 96:                 
a = sr.ReadLine();

O que pode estar causando esse problema? Observe que isso não acontece o tempo todo

Este erro geralmente significa que a máquina de destino está em execução, mas o serviço ao qual você está tentando se conectar não está disponível. (Ele parou, travou ou está ocupado com outra solicitação).

Em inglês: A conexão com a máquina (host / servidor / PC remoto em que o serviço é executado) foi feita, mas como o serviço não estava disponível em essa máquina, a máquina não sabia o que fazer com o pedido.

Se a conexão com a máquina não estiver disponível, você verá um erro diferente. Eu esqueci o que é, mas é na linha de "Serviço inacessível" ou "Indisponível".

Editar - adicionado

É possível que isso seja causado por um firewall bloqueando a porta, mas dado que você diz que é intermitente ("às vezes quando o cliente tenta se conectar"), isso é muito improvável. Eu não incluí isso originalmente porque eu havia descartado mentalmente antes de responder.

Recebi este erro ao chamar um serviço da web. O problema também estava relacionado à segurança do nível de transporte. Eu poderia chamar o serviço da web por meio de um projeto de site, mas ao reutilizar o mesmo código em um projeto de teste, receberia uma WebException que continha esta mensagem. Adicionar a seguinte linha antes de fazer a chamada resolveu o problema:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

Editar

System.Net.ServicePointManager.SecurityProtocol - Esta propriedade seleciona a versão do protocolo Secure Sockets Layer (SSL) ou Transport Layer Security (TLS) para usar apenas para novas conexões que usam o esquema HTTPS (Secure Hypertext Transfer Protocol); as conexões existentes não são alteradas.

Acredito que a SecurityProtocolconfiguração seja importante durante o handshake do TLS ao selecionar a versão do protocolo.

TLS handshake - este protocolo é usado para trocar todas as informações exigidas por ambos os lados para a troca dos dados reais do aplicativo por TLS.

ClientHello - Um cliente envia uma mensagem ClientHello especificando a versão de protocolo TLS mais alta que suporta ...

ServerHello - O servidor responde com uma mensagem ServerHello, contendo a versão do protocolo escolhida ... A versão do protocolo escolhida deve ser a mais alta que o cliente e o servidor suportam. Por exemplo, se o cliente oferece suporte a TLS versão 1.1 e o servidor oferece suporte à versão 1.2, a versão 1.1 deve ser selecionada; a versão 1.2 não deve ser selecionada.

Meu cenário de caso específico era que o serviço de aplicativo do Azure tinha a versão mínima do TLS alterada para 1.2

Não sei se esse é o padrão de agora em diante, mas alterá-lo de volta para 1.0 funcionou.

Você pode acessar a configuração em "Configurações de SSL".

Não tenho certeza de quais correções nessas postagens ajudaram, mas uma delas resolveu o problema para mim ...

http://briancaos.wordpress.com/2012/07/06/unable-to-read-data-from-the-transport-connection-the-connection-was-closed/

O truque que me ajudou foi parar de usar um WebRequest e usar um HttpWebRequest. O HttpWebRequest me permite brincar com três configurações importantes:

e

http://briancaos.wordpress.com/2012/06/15/an-existing-connection-was-forcibly-closed-by-the-remote-host/

• ETAPA 1: desative KeepAlive
• ETAPA 2: Defina ProtocolVersion para Version 10
• ETAPA 3: Limitando o número de pontos de serviço

As chamadas para serviços HTTPS de um de nossos servidores também geravam a exceção " Não foi possível ler os dados da conexão de transporte: uma conexão existente foi fechada à força ". O serviço HTTP, entretanto, funcionou bem. Usei o Wireshark para ver se era uma falha de handshake de TLS. Acabou sendo que o cipher suite no servidor precisava ser atualizado.

De acordo com as respostas de "Hans Vonn".

Adicionar a seguinte linha antes de fazer a chamada resolveu o problema:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

Depois de adicionar o protocolo de segurança e funcionando bem, mas tenho que adicionar antes de cada chamada de API que não é saudável. Acabei de atualizar a versão do framework .net para pelo menos 4.6 e, trabalhando como esperado, não preciso adicionar antes de cada chamada de API.

Isso não ajudará em problemas intermitentes, mas pode ser útil para outras pessoas com um problema semelhante.

Eu tinha clonado uma VM e inicializado em uma rede diferente com um novo endereço IP, mas não alterei as ligações no IIS. O Fiddler estava me mostrando "Não é possível ler dados da conexão de transporte: uma conexão existente foi fechada à força pelo host remoto" e o IE estava me dizendo "Ativar TLS 1.0, TLS 1.1 e TLS 1.2 nas configurações avançadas". Alterar a ligação para o novo endereço IP resolveu para mim.

Por algum motivo, a conexão com o servidor foi perdida. Pode ser que o servidor tenha encerrado explicitamente a conexão ou um bug no servidor fez com que ele fosse fechado inesperadamente. Ou algo entre o cliente e o servidor (um switch ou roteador) interrompeu a conexão.

Pode ser o código do servidor que causou o problema, mas pode não ser. Se você tiver acesso ao código do servidor, poderá colocar alguma depuração lá para avisar quando as conexões do cliente forem fechadas. Isso pode lhe dar alguma indicação de quando e por que as conexões estão sendo interrompidas.

No cliente, você deve escrever seu código para levar em consideração a possibilidade de falha do servidor a qualquer momento. É assim que as coisas são: conexões de rede são inerentemente não confiáveis.

Isso resolveu meu problema. Adicionei esta linha antes de a solicitação ser feita:

System.Net.ServicePointManager.Expect100Continue = false;

Parecia que havia um proxy no caminho do servidor que não suportava o comportamento 100-continue.

Eu tenho esse problema no passado. Estou usando PostgreSQL e quando executo meu programa, às vezes ele se conecta e às vezes ele lança um erro como esse.

Quando faço experiências com meu código, coloco meu código de conexão na primeira linha abaixo do formulário público. Aqui está um exemplo:

ANTES:

    public Form1()
        {
        //HERE LIES SOME CODES FOR RESIZING MY CONTROLS DURING RUNTIME
        //CODE
        //CODE AGAIN
        //ANOTHER CODE
        //CODE NA NAMAN
        //CODE PA RIN!





        //Connect to Database to generate auto number
        NpgsqlConnection iConnect = new NpgsqlConnection("Server=localhost;Port=5432;User ID=postgres;Password=pass;Database=DB");
        iConnect.Open();
        NpgsqlCommand iQuery = new NpgsqlCommand("Select * from table1", iConnect);
        NpgsqlDataReader iRead = iQuery.ExecuteReader();
        NpgsqlDataAdapter iAdapter = new NpgsqlDataAdapter(iQuery);

        DataSet iDataSet = new DataSet();
        iAdapter.Fill(iDataSet, "ID");

        MessageBox.Show(iDataSet.Tables["ID"].Rows.Count.ToString());
        }

AGORA:

    public Form1()
        {
        //Connect to Database to generate auto number
        NpgsqlConnection iConnect = new NpgsqlConnection("Server=localhost;Port=5432;User ID=postgres;Password=pass;Database=DB");
        iConnect.Open();
        NpgsqlCommand iQuery = new NpgsqlCommand("Select * from table1", iConnect);
        NpgsqlDataReader iRead = iQuery.ExecuteReader();
        NpgsqlDataAdapter iAdapter = new NpgsqlDataAdapter(iQuery);

        DataSet iDataSet = new DataSet();
        iAdapter.Fill(iDataSet, "ID");

        MessageBox.Show(iDataSet.Tables["ID"].Rows.Count.ToString());





        //HERE LIES SOME CODES FOR RESIZING MY CONTROLS DURING RUNTIME
        //CODE
        //CODE AGAIN
        //ANOTHER CODE
        //CODE NA NAMAN
        //CODE PA RIN!

        }

Acho que o programa deve primeiro ler a conexão antes de fazer qualquer coisa, não sei, me corrija se eu estiver errado. Mas, de acordo com minha pesquisa, não é um problema de código - na verdade, era da própria máquina.

Happy Coding!

System.Net.ServicePointManager.Expect100Continue = false;

Esse problema ocorre às vezes devido ao motivo do servidor proxy implementado no servidor web. Para ignorar o servidor proxy, colocando esta linha antes de chamar o serviço de envio.

Eu tinha um aplicativo de terceiros (Fiddler) em execução para tentar ver as solicitações enviadas. Fechar este aplicativo corrigiu isso para mim

Tivemos um problema muito semelhante, quando o site de um cliente estava tentando se conectar ao nosso serviço de API da Web e recebendo a mesma mensagem. Isso começou a acontecer do nada, quando não houve alterações de código ou atualizações do Windows no servidor onde o IIS estava sendo executado.

No nosso caso, descobriu-se que o site da chamada estava usando uma versão do .Net que suportava apenas TLS 1.0 e, por algum motivo, o servidor onde nosso IIS estava sendo executado parecia ter parado de aceitar chamadas TLS 1.0. Para diagnosticar isso, tivemos que habilitar explicitamente o TLS por meio do registro no servidor do IIS e, em seguida, reiniciar esse servidor. Estas são as chaves reg:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
    1.0\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
    1.0\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
    1.1\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
    1.1\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
    1.2\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
    1.2\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

If that doesn't do it, you could also experiment with adding the entry for SSL 2.0:


    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
    "DisabledByDefault"=dword:00000000
    "Enabled"=dword:00000001

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
    "DisabledByDefault"=dword:00000000
    "Enabled"=dword:00000001

Minha resposta a outra pergunta aqui tem este script PowerShell que usamos para adicionar as entradas:

NOTA: Habilitar protocolos de segurança antigos não é uma boa ideia, a resposta certa em nosso caso era fazer com que o site do cliente atualizasse seu código para usar TLS 1.2, mas as entradas de registro acima podem ajudar a diagnosticar o problema em primeiro lugar.

Isso estava acontecendo comigo porque eu tinha uma dependência recursiva em meu provedor de DI. No meu caso eu tinha:

services.AddScoped(provider => new CfDbContext(builder.Options));
services.AddScoped(provider => provider.GetService<CfDbContext>());

A correção era apenas remover o segundo registro de serviço com escopo

services.AddScoped(provider => new CfDbContext(builder.Options));

Se você tiver um certificado https no domínio, certifique-se de ter a ligação https ao nome de domínio no IIS. No IIS -> Selecione seu domínio -> Clique em Bindings A janela de Bindings é aberta. Adicione uma ligação para https.

Tive um problema semelhante e estava recebendo os seguintes erros, dependendo de qual aplicativo eu usei e se ignoramos o firewall / balanceador de carga ou não:

O handshake HTTPS para [blah] (para # 136) falhou. System.IO.IOException Não é possível ler os dados da conexão de transporte: Uma conexão existente foi fechada à força pelo host remoto

e

ReadResponse () falhou: O servidor não retornou uma resposta completa para este pedido. O servidor retornou 0 bytes.

O problema acabou sendo que o certificado de servidor SSL foi perdido e não foi instalado em alguns servidores.

Tente verificar se você pode estabelecer um handshake em primeiro lugar. Eu tive esse problema antes ao enviar um arquivo e só descobri que o problema era a rota inexistente quando removi o upload e verifiquei se ele pode fazer o login de acordo com os parâmetros.

Outra opção seria verificar o código de erro gerado usando o bloco try-catch e primeiro capturar uma WebException.

No meu caso, o código de erro era "SendFailure" por causa do problema do certificado no url HTTPS, uma vez que eu acessei o HTTP, isso foi resolvido.

https://docs.microsoft.com/en-us/dotnet/api/system.net.webexceptionstatus?redirectedfrom=MSDN&view=netframework-4.8

Para mim, era um problema onde na ligação do IIS tinha o endereço IP do servidor web. Eu mudei para usar todos os IPs não atribuídos e meu aplicativo começou a funcionar.

Eu encontrei o erro com python clr executando consulta mdx para serviços analíticos da Microsoft usando adomd

Resolvi com a ajuda de Hans Vonn e aqui está a versão python :

clr.AddReference("System.Net")
from System.Net import ServicePointManager, SecurityProtocolType 
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls

Para quem descobrirá isso mais tarde, após o .NET versão 4.6, eu também estava tendo esse problema.

Certifique-se de verificar seu arquivo web.config para as seguintes linhas:

<compilation debug="true" targetFramework="4.5">
...
<httpRuntime targetFramework="4.5" />

Se você estiver executando 4.6.x ou uma versão superior do .NET no servidor, certifique-se de ajustar esses valores de targetFramework para corresponder à versão da estrutura em seu servidor. Se suas versões forem inferiores a 4.6.x, eu recomendaria que você atualize o .NET e use a versão mais recente, a menos que seu código dependa de uma versão mais antiga (que, nesse caso, você deve considerar atualizá-lo).

Mudei targetFrameworks para 4.7.2 e o problema desapareceu:

<compilation debug="true" targetFramework="4.7.2">
...
<httpRuntime targetFramework="4.7.2" />

As estruturas mais recentes resolvem esse problema usando o melhor protocolo disponível e bloqueando os inseguros ou obsoletos. Se o serviço remoto ao qual você está tentando se conectar ou ligar estiver apresentando esse erro, pode ser que eles não suportem mais os protocolos antigos.