Steam साइन-इन काम गर्छ, गेम गर्दैन: प्रत्येक मार्ग जाँच्नुहोस्

Steam खोल्नुहोस्, साइन-इन गर्नुहोस्, र गेमले सत्र भेट्टाउन नसकेसम्म सबै ठीक देखिन्छ। यसलाई एउटा होइन, तीन छुट्टै नेटवर्क प्रश्नका रूपमा लिनुहोस्। स्टोर र खाता स्क्रिन, सामग्री डाउनलोड र गेम सत्र प्रत्येकले फरक फरक ट्रान्सपोर्टमार्फत फरक फरक अन्त्य बिन्दुहरूमा पुग्न सक्छन्। यी जाँचहरू क्रममा गर्नुहोस् र पहिलो असफल हुनेमा रोक्नुहोस्, किनकि त्यसपछिको सबै अनुमान हो।

चरण 1: साइन-इन मात्र काम गरेको हो भनी पुष्टि गर्नुहोस्

साइन-इनले खाता प्रमाणहरू र खातालाई आवश्यक पर्ने कुनै पनि दोस्रो कारकसहित पहिचान सेवासम्म पुगेको प्रमाणित गर्छ। यसले सामग्री वितरणबारे केही भन्दैन र गेमको आफ्नै होस्टिङ व्यवस्थाबारे पनि केही भन्दैन। तीनमध्ये कुन कार्य तपाईंले वास्तवमा परीक्षण गर्नुभयो लेख्नुहोस्, किनकि मानिसहरू प्रायः लन्चर मात्र परीक्षण गरेपछि असफल गेमको रिपोर्ट गर्छन्।

नेटवर्कभन्दा पहिले असफलताको पाठ पढ्नुहोस्। कुनै सर्भर उपलब्ध छैन भनी रिपोर्ट गर्ने गेमले तपाईंलाई स्टोरमा पुग्न नसक्ने लन्चरभन्दा फरक कुरा बताउँछ। दुवै त्रुटि फरक तहबाट आउँछन् र विरलै एउटै अर्थ दिन्छन्। यो भिन्नताले अर्को जाँच नाम समाधान, UDP, वा क्षेत्र सेटिङसँग सम्बन्धित छ कि भनेर निर्धारण गर्छ।

खाता, क्षेत्र, गेम र समय लेख्नुहोस्। ती चार मानबिना, पछिको तुलना एउटै नाम संयोगवश साझा गर्ने दुई फरक परीक्षणबीच हुनेछ।

चरण 2: प्रत्येक कार्यका लागि ट्रान्सपोर्टको नाम दिनुहोस्

सामग्री वितरण ठूलो HTTP स्थानान्तरणजस्तै व्यवहार गर्छ र हानिभन्दा ढिलाइ धेरै राम्रोसँग सहन्छ। म्याचमेकिङ र गेमभित्रका सत्रहरू प्रायः UDP प्रयोग गर्छन्, जहाँ प्याकेट खसाल्ने मार्ग ढिलो डाउनलोडको सट्टा बिग्रिएको गेमजस्तो देखिन्छ। ती दुई प्रोफाइल एउटै सुरुङमा फरक रूपमा असफल हुन्छन्, त्यसैले छिटो डाउनलोडले काम गर्ने सत्रको भविष्यवाणी गर्दैन।

पहिले विक्रेताको पोर्ट सूचीको सट्टा गन्तव्यहरू र सक्रिय सकेटहरू जाँच्नुहोस्। सूचीले प्लेटफर्मले के प्रयोग गर्न सक्छ भन्छ, जबकि सकेटहरूले यो क्लाइन्ट अहिले के गर्दैछ भन्छन्।

nslookup api.steampowered.com
ss -uanp | head -20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://store.steampowered.com/

यदि गेम प्रक्रियाले ट्राफिक भएको UDP सकेट राख्छ जबकि स्थानान्तरण मार्ग ठीक छ, असफलता UDP भागमा छ। यसले समस्यालाई खाता वा स्टोरको सट्टा सुरुङको UDP व्यवस्थापनसम्म सीमित गर्छ।

चरण 3: पोर्ट सूचीभन्दा पहिले समावेश नीति जाँच्नुहोस्

धेरै VPN क्लाइन्टले पूरै मेसिनको सट्टा प्रत्येक एप्लिकेसन, ठेगाना दायरा वा ठेगाना परिवारका लागि नीति लागू गर्छन्। लन्चर सुरुङभित्र हुन सक्छ जबकि छुट्टै सुरु गरिएको गेम बाइनरी त्यसको बाहिर हुन्छ, र त्यसपछि दुवै संसारबारे सहमत हुँदैनन्। एप्लिकेसन-स्तरीय समावेश विक्रेता क्लाइन्ट स्थापना गरिएको गेमिङ ल्यापटपमा सामान्य दोषी हो। गएको महिना सुरक्षित गरिएको प्रोफाइल होइन, वास्तवमा लागू रहेको नीति पढ्नुहोस्।

रुट तालिका र पूर्वनिर्धारित रुट भएको इन्टरफेस हेर्नुहोस्। गन्तव्य प्रिफिक्समा आधारित स्प्लिट-टनेल नियम त्यहाँ देखिन्छ, र एप्लिकेसन-स्तरीय बहिष्करण देखिँदैन। तीमध्ये कुनै पनि परिवर्तन गर्नुअघि यो भिन्नता जान्नु राम्रो हुन्छ।

ip route show default
ip -brief addr
Get-NetAdapter | Select-Object Name, Status, InterfaceDescription

यदि गेमको ट्राफिक भौतिक एडाप्टरबाट बाहिर जान्छ जबकि स्टोर सुरुङबाट जान्छ, समावेश नीति नै निष्कर्ष हो। कुनै पोर्ट अपवादले रुटिङ निर्णय सुधार्ने छैन, र एउटा थप्दा केवल सतह फराकिलो हुन्छ।

चरण 4: UDP बोक्न नसक्ने SOCKS मार्ग बाहिर राख्नुहोस्

Tor ले SOCKS प्रोक्सी दिन्छ, र सम्पूर्ण इकोसिस्टममा SOCKS समर्थन UDP सम्बन्धमा असंगत छ। Tor को अभिलेखित व्यवहारले UDP ASSOCIATE लागू गर्दैन, त्यसैले जसको सत्र ट्राफिक UDP छ त्यस्तो गेमले क्लाइन्ट जसरी पनि त्यतातिर निर्देशित गरिए पनि त्यो मार्ग प्रयोग गर्न सक्दैन। प्रोक्सीमार्फत चल्ने ब्राउजरले ब्राउजरका TCP प्रवाहहरू चल्छन् भन्ने मात्र प्रमाणित गर्छ।

नियत होइन, दाबी परीक्षण गर्नुहोस्। यदि त्यही प्रोक्सीमार्फत TCP मात्र परीक्षण सफल हुँदा पनि गेमले अझै अनुपलब्ध सत्र रिपोर्ट गर्छ भने, प्रोक्सी मार्गले गेमलाई आवश्यक ट्राफिक बोक्दैन।

रुट गरिएको VPN र SOCKS प्रोक्सीलाई फरक क्षमता भएका फरक उपकरणका रूपमा लिनुहोस्। एउटालाई अर्कोले बदल्नु कन्फिगरेसन प्राथमिकता होइन, डिजाइन परिवर्तन हो।

अभिलेखलाई सम्झौतासँग भिडाउनुहोस्

नेटवर्क पहुँच र खाता अनुमति फरक प्रश्न हुन्, र पहिलोको मात्र जवाफ काम गर्ने सुरुङले दिन्छ। प्रतिबन्धले तपाईंले छानेको प्रोटोकलको होइन, प्रोक्सी गर्ने पछाडिको नियतको कुरा गर्छ। लागू सम्झौताले खाताधारक कहाँ बस्छ भन्ने लुकाउने उद्देश्यको IP प्रोक्सीलाई सीमित गर्छ, त्यसैले काम गर्ने मार्ग पनि तपाईंले स्वीकार गरेका सर्तबाहिर हुन सक्छ। जडानलाई स्वीकृति मान्नुको सट्टा सम्झौता पढ्नुहोस्।

इमानदार तुलनाका लागि, एकै पटक एक चर परिवर्तन गर्नुहोस् र उही गेम, सर्भर क्षेत्र, खाता र कार्य राख्नुहोस्। त्यसपछि सुरुमा लेखिएका ती चारै कार्यमा नतिजा जाँच्नुहोस्।

tracert -h 12 store.steampowered.com
ss -uanp | grep -i -E 'game|steam'
curl -sS -o /dev/null -w '%{remote_ip} %{time_connect}\n' https://store.steampowered.com/

जब अभिलेखले साइन-इन काम गरिरहेको, डाउनलोड काम गरिरहेको र सत्र असफल भइरहेको देखाउँछ, बाँकी प्रश्न मार्गको UDP बारे हो। तीनै काम गर्दा, मूल गुनासो अरू कुनै कुराबारे थियो, र अर्को उपयोगी कदम सुरुङ होइन, गेमको आफ्नै लग हो। जसरी भए पनि, चेकलिस्टले बहसलाई ठोस अवलोकनले बदलेको छ।