Mam aplikację serwerową i czasami, gdy klient próbuje się połączyć, pojawia się następujący błąd:
UWAGA: komunikat „Nie można pobrać strumienia z klienta lub logowanie nie powiodło się” to tekst, który został dodany przeze mnie w instrukcji catch
a linia, na której się kończy (sThread: line 96) to:
tcpClient = (TcpClient)client;
clientStream = tcpClient.GetStream();
sr = new StreamReader(clientStream);
sw = new StreamWriter(clientStream);
// line 96:
a = sr.ReadLine();
Co może być przyczyną tego problemu? Pamiętaj, że nie zdarza się to cały czas
źródło
Otrzymałem ten błąd podczas dzwonienia do serwisu internetowego. Problem dotyczył również bezpieczeństwa na poziomie transportu. Mógłbym wywołać usługę sieciową za pośrednictwem projektu witryny internetowej, ale podczas ponownego użycia tego samego kodu w projekcie testowym otrzymywałbym wyjątek WebException zawierający tę wiadomość. Dodanie następującego wiersza przed nawiązaniem połączenia rozwiązało problem:
Edytować
Uważam, że
SecurityProtocol
konfiguracja jest ważna podczas uzgadniania TLS podczas wybierania wersji protokołu.źródło
Mój konkretny scenariusz polegał na tym, że usługa aplikacji platformy Azure miała minimalną wersję TLS zmienioną na 1.2
Nie wiem, czy od teraz jest to ustawienie domyślne, ale zmiana z powrotem na 1.0 sprawiła, że zadziałało.
Możesz uzyskać dostęp do ustawienia w „Ustawieniach SSL”.
źródło
Nie jestem pewien, która z poprawek w tych postach na blogu pomogła, ale jedna z nich rozwiązała ten problem dla mnie ...
http://briancaos.wordpress.com/2012/07/06/unable-to-read-data-from-the-transport-connection-the-connection-was-closed/
Sztuczka, która mi pomogła, polegała na tym, że przestałem używać WebRequest i zamiast tego użyć HttpWebRequest. HttpWebRequest pozwala mi grać z 3 ważnymi ustawieniami:
i
http://briancaos.wordpress.com/2012/06/15/an-existing-connection-was-forcibly-closed-by-the-remote-host/
źródło
Wywołania do usług HTTPS z jednego z naszych serwerów generowały również wyjątek „ Nie można odczytać danych z połączenia transportowego: istniejące połączenie zostało przymusowo zamknięte ”. Usługa HTTP działała jednak dobrze. Użył Wiresharka, aby zobaczyć, że był to błąd uzgadniania TLS. Skończyło się na tym, że zestaw szyfrów na serwerze wymagał aktualizacji.
źródło
Według odpowiedzi „Hansa Vonna”.
Dodanie następującego wiersza przed nawiązaniem połączenia rozwiązało problem:
Po dodaniu protokołu Security i działaniu dobrze, ale muszę dodawać przed każdym wywołaniem API, które nie jest zdrowe. Po prostu aktualizuję platformę .net do wersji co najmniej 4.6 i działając zgodnie z oczekiwaniami nie wymagam dodawania przed każdym wywołaniem API.
źródło
Nie pomoże to w przypadku sporadycznych problemów, ale może być przydatne dla innych osób z podobnym problemem.
Sklonowałem maszynę wirtualną i uruchomiłem ją w innej sieci z nowym adresem IP, ale nie zmieniłem powiązań w usługach IIS. Fiddler pokazywał mi komunikat „Nie można odczytać danych z połączenia transportowego: istniejące połączenie zostało przymusowo zamknięte przez hosta zdalnego”, a przeglądarka Internetowa poinformowała mnie „Włącz TLS 1.0, TLS 1.1 i TLS 1.2 w ustawieniach zaawansowanych”. Zmiana powiązania na nowy adres IP rozwiązała to za mnie.
źródło
Z jakiegoś powodu połączenie z serwerem zostało utracone. Może się zdarzyć, że serwer jawnie zamknął połączenie lub błąd na serwerze spowodował nieoczekiwane zamknięcie połączenia. Lub coś między klientem a serwerem (przełącznik lub router) zrywało połączenie.
Może to być kod serwera, który spowodował problem, a może nie. Jeśli masz dostęp do kodu serwera, możesz umieścić tam trochę debugowania, aby poinformować Cię, kiedy połączenia klientów są zamykane. To może dać ci pewne wskazówki, kiedy i dlaczego połączenia są przerywane.
Na kliencie musisz napisać swój kod, aby uwzględnić możliwość awarii serwera w dowolnym momencie. Po prostu tak jest: połączenia sieciowe są z natury zawodne.
źródło
To rozwiązało mój problem. Dodałem tę linię przed wysłaniem żądania:
Wydawało się, że na drodze serwera znajduje się proxy, które nie obsługuje zachowania kontynuacji 100.
źródło
Mam ten problem w przeszłości. Używam PostgreSQL i kiedy uruchamiam mój program, czasami się łączy, a czasami wyświetla taki błąd.
Kiedy eksperymentuję z kodem, umieszczam kod połączenia w pierwszym wierszu poniżej formularza publicznego. Oto przykład:
PRZED:
TERAZ:
Myślę, że program musi najpierw przeczytać połączenie, zanim cokolwiek zrobi, nie wiem, popraw mnie, jeśli się mylę. Ale według moich badań nie jest to problem z kodem - w rzeczywistości pochodzi z samej maszyny.
Miłego kodowania!
źródło
Ten problem czasami występuje z powodu serwera proxy zaimplementowanego na serwerze WWW. Aby ominąć serwer proxy, umieszczając tę linię przed wywołaniem usługi wysyłania.
źródło
Miałem uruchomioną aplikację innej firmy (Fiddler), aby spróbować zobaczyć wysyłane żądania. Zamknięcie tej aplikacji rozwiązało problem
źródło
Mieliśmy bardzo podobny problem, w którym witryna klienta próbowała połączyć się z naszą usługą interfejsu API sieci Web i otrzymać tę samą wiadomość. Zaczęło się to zupełnie nieoczekiwanie, kiedy nie było żadnych zmian kodu ani aktualizacji systemu Windows na serwerze, na którym były uruchomione usługi IIS.
W naszym przypadku okazało się, że strona wywołująca używa wersji .Net, która obsługuje tylko TLS 1.0 iz jakiegoś powodu serwer, na którym działały nasze IIS, przestał przyjmować połączenia TLS 1.0. Aby zdiagnozować, że musieliśmy jawnie włączyć TLS przez rejestr na serwerze IIS, a następnie ponownie uruchomić ten serwer. Oto klucze reg:
Moja odpowiedź na inne pytanie dotyczy tego skryptu PowerShell, którego użyliśmy do dodania wpisów:
UWAGA: Włączenie starych protokołów bezpieczeństwa nie jest dobrym pomysłem, właściwą odpowiedzią w naszym przypadku było skłonienie witryny klienta do zaktualizowania swojego kodu do korzystania z TLS 1.2, ale powyższe wpisy rejestru mogą pomóc zdiagnozować problem w pierwszej kolejności.
źródło
Powodem tego było to, że miałem rekursywną zależność u mojego dostawcy DI. W moim przypadku miałem:
Naprawiono po prostu usunięcie drugiej rejestracji usługi w zakresie
źródło
Jeśli masz certyfikat https w domenie, upewnij się, że masz powiązanie https z nazwą domeny w usługach IIS. W usługach IIS -> Wybierz domenę -> Kliknij opcję Powiązania Otworzy się okno Powiązania witryny. Dodaj powiązanie dla https.
źródło
Miałem podobny problem i otrzymywałem następujące błędy w zależności od używanej aplikacji i czy ominęliśmy zaporę / system równoważenia obciążenia, czy nie:
i
Problem polegał na tym, że certyfikat serwera SSL został pominięty i nie został zainstalowany na kilku serwerach.
źródło
Spróbuj najpierw sprawdzić, czy możesz ustalić uścisk dłoni. Miałem ten problem wcześniej podczas przesyłania pliku i doszedłem do wniosku, że problem dotyczy nieistniejącej trasy, gdy usunąłem przesyłanie i sprawdziłem, czy można się zalogować, biorąc pod uwagę parametry.
źródło
Inną opcją byłoby sprawdzenie kodu błędu wygenerowanego za pomocą bloku try-catch i najpierw przechwycenie WebException.
W moim przypadku kod błędu to „SendFailure” z powodu problemu z certyfikatem na adresie URL HTTPS, który został rozwiązany po kliknięciu HTTP.
https://docs.microsoft.com/en-us/dotnet/api/system.net.webexceptionstatus?redirectedfrom=MSDN&view=netframework-4.8
źródło
Dla mnie był to problem polegający na tym, że w powiązaniu IIS miał adres IP serwera internetowego. Zmieniłem to, aby używać wszystkich nieprzypisanych adresów IP i moja aplikacja zaczęła działać.
źródło
Wystąpił błąd podczas wykonywania zapytania mdx do usług analitycznych firmy Microsoft przy użyciu narzędzia adomd w języku Python
Rozwiązałem to z pomocą Hansa Vonna i oto wersja w Pythonie :
źródło
Dla tych, którzy mogą znaleźć to później, po wersji .NET 4.6, również napotkałem ten problem.
Upewnij się, że w pliku web.config znajdują się następujące wiersze:
Jeśli korzystasz z 4.6.x lub nowszej wersji platformy .NET na serwerze, upewnij się, że dostosujesz te wartości targetFramework, aby pasowały do wersji platformy na serwerze. Jeśli twoje wersje czytają mniej niż 4.6.x, to polecam aktualizację .NET i używanie nowszej wersji, chyba że twój kod jest zależny od starszej wersji (co w takim przypadku należy rozważyć aktualizację).
Zmieniłem targetFrameworks na 4.7.2 i problem zniknął:
Nowsze frameworki rozwiązują ten problem, używając najlepszego dostępnego protokołu i blokując niezabezpieczone lub przestarzałe. Jeśli usługa zdalna, z którą próbujesz się połączyć lub wywołać, zgłasza ten błąd, może to oznaczać, że nie obsługują już starych protokołów.
źródło