VPN मार्फत iPhone एपबाट आन्तरिक API कसरी कल गर्ने

API त्यही फोनको Safari मा जवाफ दिन्छ, तर एपको अनुरोध समयसीमा नाघ्छ। यो अन्तर सामान्यतया टनेल होइन: आन्तरिक सेवा कल गर्ने एपले साधारण HTTPS अनुरोध गर्छ, र यन्त्रमा रहेको विद्यमान VPN ले त्यो अनुरोधको मार्ग छ कि छैन मात्र निर्धारण गर्छ। एपभित्र दोस्रो टनेल लेख्नु उत्पादन निर्णय हो, समयसीमाको लागि मर्मत होइन। तलको भाग असफलतालाई यो कहाँ हुन्छ भन्ने आधारमा वर्गीकरण गर्छ, एपसँग पहिले नै रहेको त्रुटि-सतह प्रयोग गरेर।

टनेलबाट होइन, त्रुटिबाट सुरु गर्नुहोस्

URLSession यातायात असफलताहरूलाई NSError मानका रूपमा NSURLErrorDomain मा रिपोर्ट गर्छ, र कोड नै सबैभन्दा सस्तो उपलब्ध प्रमाण हो। कुनै पनि कन्फिगरेसन बदल्नु अघि त्यो कोड असफल हुने होस्टनाम र कार्यको बितेको समयसँगै लग गर्नुहोस्। समयसीमा, नाम असफलता र विश्वास असफलता स्क्रिनमा उस्तै देखिन्छन् र तीन फरक मर्मत आवश्यक पर्छ। पहिले वर्गीकरण गर्नुहोस्, त्यसपछि त्यो वर्गको खण्ड पढ्नुहोस्।

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

नाम-समाधान अरू जेभन्दा पहिले असफल हुन्छ

उदाहरणका लागि api.corp.example जस्तो छोटो कार्यालय नाम सामान्यतया फोनमा नभएको खोज डोमेनमा निर्भर हुन्छ, त्यसैले एप भवनभित्र मात्र रहेको नाम समाधान गर्छ। NSURLErrorCannotFindHost त्यसको हस्ताक्षर हो। पूरा होस्टनाम VPN ले स्थापना गर्ने जुनसुकै रिजोल्भरबाट समाधान गरिनुपर्छ, र खोज डोमेनको ग्यारेन्टी नभएको बेला एपले पूर्ण रूपमा योग्य रूप माग्नुपर्छ। नामलाई ठेगानाले बदल्नु र प्रमाणपत्र जाँच बन्द गर्नु असफलतालाई मर्मत गर्नुको सट्टा सार्नु हो।

निजी DNS रेकर्ड र ठ्याक्कै त्यही नामका लागि जारी गरिएको प्रमाणपत्र समर्थित जोडी हुन्। बाँकी सबै प्रयोगकर्तासम्म पुग्ने एउटा उपाय हो।

समयसीमा नामको प्रश्न होइन, मार्गको प्रश्न हो

NSURLErrorTimedOut नाम समाधान भयो र केहीले जवाफ दिएन भन्ने अर्थ हुन्छ, जसले मार्ग, प्याकेट नीति वा सेवातर्फ संकेत गर्छ। टनेल प्रत्येक एप्लिकेसनका लागि तोकिँदा त्यही सर्भरमा पुग्ने अर्को एपले तपाईंको बिल्डबारे केही भन्दैन, किनकि त्यो म्यापिङ साझा गरिँदैन। तपाईंले चलाइरहेको बन्डल त्यो तोकाइभित्र छ कि छैन जाँच्नुहोस्, त्यसपछि सेवाको मार्ग त्यसका लागि अनुमति छ कि छैन जाँच्नुहोस्। तोकाइबाहिर स्थापना गरिएको विकास बिल्ड पूर्ण रूपमा टनेलबाहिर रहन सक्छ र भाँचिएको API जस्तो देखिन सक्छ।

ब्राउजर तुलनाले यन्त्रको कुनै एपसँग मार्ग छ भनी देखाउँछ। यसले तपाईंको बिल्डसँग छ भनी कहिल्यै प्रमाणित गर्दैन, त्यसैले दुई परीक्षण अलग गर्नुपर्छ।

विश्वास असफलताहरू प्रमाणपत्रमा भएको नामसँग सम्बन्धित छन्

NSURLErrorServerCertificateUntrusted त्यसको तलको TLS त्रुटिसँगै भन्नाले श्रृंखला वा पहिचान जाँच असफल भयो। आन्तरिक CA यन्त्रमा विश्वसनीय हुनुपर्छ, र अर्को होस्टनामका लागि जारी गरिएको प्रमाणपत्र जतिसुकै नेटवर्क पुनर्संरचना भए पनि गलत नै रहन्छ। Apple को App Transport Security मार्गदर्शन यी URL लोड गर्ने जडानहरूमा अझै लागू हुन्छ, र साधारण HTTP सेवाको वरिपरि टनेलले त्यो सेवालाई छेउदेखि छेउसम्म सुरक्षित बनाउँदैन।

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

HTTP अस्वीकृति एपको हो, नेटवर्कको होइन

पूरा भएको ह्यान्डशेकपछि 401 वा 403 भन्नाले अनुरोध पुग्यो र सेवाले अस्वीकार गर्यो, त्यसैले बाँकी प्रश्न खाता, टोकन दर्शक, दायरा वा कुञ्जी हो। स्थिति कोड र होस्टनाम लग गर्नुहोस्, कहिल्यै बियरर टोकन वा प्रतिक्रिया मुख्य भाग होइन। त्यो बेला टनेल आफ्नो काम गरिरहेको हुन्छ र थप नेटवर्क परिवर्तनले वास्तविक सुधार मात्र ढिलो गर्छ।

तालिका टर्मिनलको छेउमा राख्ने वर्गीकरण हो: एपले साँच्चै रिपोर्ट गर्न सक्ने हरेक असफलताका लागि एक पंक्ति। कोड पढ्नु अघि छाप्नुहोस्, किनकि तपाईंले छान्ने पंक्तिले कुन खण्डमा काम गर्ने भन्ने निर्धारण गर्छ।

हरेक पंक्ति त्यसको तलको भन्दा सस्तोमा परीक्षण गर्न सकिन्छ, र हरेकले त्यही अनुरोधको फरक तह बाहिर राख्छ। पंक्ति मिल्नेसम्म तालिकामा तल जानुहोस्, त्यसपछि नेटवर्क बदल्न छोड्नुहोस्।