전송 연결에서 데이터를 읽을 수 없습니다. 기존 연결이 원격 호스트에 의해 강제로 닫혔습니다.

전송 연결에서 데이터를 읽을 수 없습니다. 기존 연결이 원격 호스트에 의해 강제로 닫혔습니다.

---

서버 앱이 있고 때로는 클라이언트가 연결을 시도 할 때 다음 오류가 발생합니다.

참고 : "클라이언트에서 스트림을 가져올 수 없거나 로그인 실패"는 catch 문에 추가 된 텍스트입니다.

중지되는 줄 (sThread : 줄 96)은 다음과 같습니다.

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

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

이 문제의 원인은 무엇입니까? 항상 발생하는 것은 아닙니다.

---

이 오류는 일반적으로 대상 컴퓨터가 실행 중이지만 연결하려는 서비스를 사용할 수 없음을 의미합니다. (중지, 충돌 또는 다른 요청으로 사용 중입니다.)

받는 사람 연결 : 영어 기계 되었다하지만 서비스를 사용할 수 없을 때부터 (서비스 실행에서 그 원격 호스트 / 서버 / PC) 에 그 기계, 기계가 요청에 무엇을 해야할지하지 않았다.

기기에 연결할 수없는 경우 다른 오류가 표시됩니다. 나는 그것이 무엇인지 잊어 버렸습니다. 그러나 그것은 "Service Unreachable"또는 "Unavailable"라인을 따라 있습니다.

편집-추가

포트를 차단하는 방화벽이 원인 일 수 있지만 간헐적 ( "때때로 클라이언트가 연결을 시도 할 때")이라고 말하면 그럴 가능성이 거의 없습니다. 답장하기 전에 정신적으로 배제했기 때문에 원래 포함하지 않았습니다.

---

웹 서비스를 호출 할 때이 오류가 발생했습니다. 이 문제는 전송 수준 보안과도 관련이 있습니다. 웹 사이트 프로젝트를 통해 웹 서비스를 호출 할 수 있지만 테스트 프로젝트에서 동일한 코드를 재사용하면이 메시지가 포함 된 WebException이 발생합니다. 전화를 걸기 전에 다음 줄을 추가하면 문제가 해결되었습니다.

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

편집하다

System.Net.ServicePointManager.SecurityProtocol- 이 속성은 HTTPS (Secure Hypertext Transfer Protocol) 체계 만 사용하는 새 연결에 사용할 SSL (Secure Sockets Layer) 또는 TLS (전송 계층 보안) 프로토콜의 버전을 선택합니다. 기존 연결은 변경되지 않습니다.

SecurityProtocol프로토콜 버전을 선택할 때 TLS 핸드 셰이크 중에 구성이 중요 하다고 생각합니다 .

TLS handshake - This protocol is used to exchange all the information required by both sides for the exchange of the actual application data by TLS.

ClientHello - A client sends a ClientHello message specifying the highest TLS protocol version it supports ...

ServerHello - The server responds with a ServerHello message, containing the chosen protocol version ... The chosen protocol version should be the highest that both the client and server support. For example, if the client supports TLS version 1.1 and the server supports version 1.2, version 1.1 should be selected; version 1.2 should not be selected.

---

My specific case scenario was that the Azure app service had the minimum TLS version changed to 1.2

I don't know if that's the default from now on, but changing it back to 1.0 made it work.

You can access the setting inside "SSL Settings".

---

Not sure which of the fixes in these blog posts helped, but one of them sorted this issue for me ...

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

The trick that helped me was to quit using a WebRequest and use a HttpWebRequest instead. The HttpWebRequest allows me to play with 3 important settings:

and

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

• STEP 1: Disable KeepAlive
• STEP 2: Set ProtocolVersion to Version10
• STEP 3: Limiting the number of service points

---

Calls to HTTPS services from one of our servers were also throwing the "Unable to read data from the transport connection : An existing connection was forcibly closed" exception. HTTP service, though, worked fine. Used Wireshark to see that it was a TLS handshake Failure. Ended up being that the cipher suite on the server needed to be updated.

---

This won't help for intermittent issues, but may be useful for other people with a similar problem.

I had cloned a VM and started it up on a different network with a new IP address but not changed the bindings in IIS. Fiddler was showing me "Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host" and IE was telling me "Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings". Changing the binding to the new IP address solved it for me.

---

For some reason, the connection to the server was lost. It could be that the server explicitly closed the connection, or a bug on the server caused it to be closed unexpectedly. Or something between the client and the server (a switch or router) dropped the connection.

It might be server code that caused the problem, and it might not be. If you have access to the server code, you can put some debugging in there to tell you when client connections are closed. That might give you some indication of when and why connections are being dropped.

On the client, you have to write your code to take into account the possibility of the server failing at any time. That's just the way it is: network connections are inherently unreliable.

---

I get that problem in the past. I'm using PostgreSQL and when I run my program, sometimes it connects and sometimes it throws an error like that.

When I experiment with my code, I put my Connection code at the very first line below the public Form. Here is an example:

BEFORE:

    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());
        }

NOW:

    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!

        }

I think that the program must read first the connection before doing anything, I don't know, correct me if I'm wrong. But according to my research, it's not a code problem - it was actually from the machine itself.

Happy Coding!

---

This solved my problem. I added this line before the request is made:

System.Net.ServicePointManager.Expect100Continue = false;

It seemed there were a proxy in the way of the server that not supported 100-continue behavior.

---

System.Net.ServicePointManager.Expect100Continue = false;

This issue sometime occurs due the reason of proxy server implemented on web server. To bypass the proxy server by putting this line before calling the send service.

---

I had a Third Party application (Fiddler) running to try and see the requests being sent. Closing this application fixed it for me

---

We had a very similar issue whereby a client's website was trying to connect to our Web API service and getting that same message. This started happening completely out of the blue when there had been no code changes or Windows updates on the server where IIS was running.

In our case it turned out that the calling website was using a version of .Net that only supported TLS 1.0 and for some reason the server where our IIS was running stopped appeared to have stopped accepting TLS 1.0 calls. To diagnose that we had to explicitly enable TLS via the registry on the IIS's server and then restart that server. These are the reg keys:

[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

My answer to another question here has this powershell script that we used to add the entries:

NOTE: Enabling old security protocols is not a good idea, the right answer in our case was to get the client website to update it's code to use TLS 1.2, but the registry entries above can help diagnose the issue in the first place.

---

The reason this was happening to me was I had a recursive dependency in my DI provider. In my case I had:

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

Fix was to just remove the second scoped service registration

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

---

If you have a https certificate on the domain, make sure you have the https binding to the domain name in IIS. In IIS -> Select your domain -> Click on Bindings Site Bindings Window opens up. Add a binding for https.

---

Had a similar problem and was getting the following errors depending on what app I used and if we bypassed the firewall / load balancer or not:

HTTPS handshake to [blah] (for #136) failed. System.IO.IOException Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host

and

ReadResponse() failed: The server did not return a complete response for this request. Server returned 0 bytes.

The problem turned out to be that the SSL Server Certificate got missed and wasn't installed on a couple servers.

---

Try checking if you can establish handshake in the first place. I had this issue before when uploading a file and I only figured out that the issue was the nonexistent route when I removed the upload and checked if it can login given the parameters.

참고URL : https://stackoverflow.com/questions/5420656/unable-to-read-data-from-the-transport-connection-an-existing-connection-was-f