WebSocket 1006 არ გეუბნებათ, რომელი რგოლი გაწყდა
წაიკითხეთ WebSocket-ის არანორმალური დახურვა როგორც Close handshake-ის ნაკლული მტკიცებულება, შემდეგ დაადგინეთ, ჩავარდა proxy-ის კონფიგურაცია თუ უკვე დამყარებული სესია.
WebSocket-ის კოდი 1006 იუწყება არანორმალურ დახურვაზე მოსალოდნელი Close ჩარჩოს გარეშე. კოდი დაცულია: საბოლოო წერტილმა არ უნდა გაგზავნოს 1006 როგორც სტატუსი WebSocket-ის Close ჩარჩოში. მისი API მოვლენაში ნახვა არ არის სერვერის შეტყობინება, რომელიც proxy-ს მიზეზად დაასახელებს.
თუ კავშირი არასოდეს გახსნილა
მიჰყევით კონფიგურაციას თანმიმდევრობით: კავშირი proxy-სთან, proxy-ს მოლაპარაკება, დანიშნულების TLS WSS-ისთვის, შემდეგ WebSocket-ის გახსნის handshake. proxy-ს გამოწვევამ ან გვირაბის უარყოფამ შეიძლება შეაჩეროს მიმდევრობა WebSocket-ის ეტაპამდე.
თუ გაიხსნა და შეტყობინებები გადაიტანა
ჩაწერეთ გამოსადეგი ხანგრძლივობა და რაც დახურვამდე მოხდა. ტრანსპორტის შეფერხებამ, აპლიკაციის გამორთვამ და შუამავლის პოლიტიკამ შეიძლება მიმღები დატოვოს სუფთა დახურვის გაცვლის გარეშე.
შეინახეთ საბოლოო წერტილი, სესიის იდენტიფიკატორი, ბოლო აქტივობა და დაფიქსირდა თუ არა ჩვეულებრივი Close ჩარჩო. შეადარეთ ბრაუზერის ან ბიბლიოთეკის ქსელური შეცდომები თქვენს მიერ კონტროლირებულ დანიშნულების ჟურნალებს. მხოლოდ მოვლენის კოდი ვერ დაადგენს ISP-ს, proxy-ის ოპერატორს ან აპლიკაციის სერვერს როგორც წყაროს.
იმავე proxy-ზე გამავალი ჩვეულებრივი HTTPS გვერდი ამოწმებს მოკლე გაცვლას, არა ამ სესიის სიცოცხლეს. მარშრუტის შეცვლისას ბრაუზერის მდგომარეობა და აპლიკაციის კოდი უცვლელად შეინახეთ; თორემ წარმატებული გამეორება ძნელი გასაგებია.
შეაკეთეთ ის საზღვარი, რომელსაც მტკიცებულებები უჭერენ მხარს. proxy-ს ავთენტიფიკაცია, TLS-ის ნდობა და აპლიკაციის ხელახალი დაკავშირება ცალკეული სამუშაოებია და ყველა ვადის გაზრდა ვერ აიძულებს 1006-ს, დაასახელოს ერთი მათგანი.