કેટલીક વેબસાઇટ ફક્ત VPN ચાલુ હોય ત્યારે જ કેમ નિષ્ફળ જાય છે?

એક સાઇટ નિષ્ફળ જાય જ્યારે બાકીનું બધું લોડ થતું હોય, તે સાબિત કરે છે કે ટનલ ટ્રાફિક લઈ જાય છે, અને તે સમસ્યાને મોટા ભાગના લોકો ધારે છે તેના કરતાં વધુ મર્યાદિત કરે છે. ત્રણ અવલોકનો બાકીનું ગોઠવે છે: તમને HTTP પ્રતિસાદ મળ્યો કે નહીં, હોસ્ટનામ સરનામામાં ઉકેલાયું કે નહીં, અને નાની વિનંતીઓ પસાર થાય છે જ્યારે મોટી અટકે છે કે નહીં. આ જવાબો પહેલાં VPN વિશે અનુમાન કરવું સામાન્ય રીતે ખામી દૂર કરવાને બદલે તેનું સ્થાન બદલે છે.

અવલોકનો ક્રમમાં સંભાળો, કારણ કે જે સાઇટે જવાબ આપ્યો તે એકસાથે ઉકેલમાં નિષ્ફળ થઈ શકે નહીં. જો કંઈ પણ લોડ ન થાય, તો તમે ખોટી શાખામાં છો, અને જોડાયેલ પણ ઇન્ટરનેટ વગરની સ્થિતિની ચકાસણીઓ લાગુ પડે છે.

ભૂલ સંદેશને શાખા પસંદ કરવા દો

ઇનકાર, બોટ-પડકાર કે ભૂલ પૃષ્ઠનો અર્થ છે કે સેવાએ જવાબ આપ્યો, એટલે પેકેટ કોઈ એપ્લિકેશન સુધી પહોંચ્યા અને પાછા ફર્યા. આ પ્રશ્નને સાઇટની ઍક્સેસ નીતિ તરફ ખસેડે છે, જે નિકાસ સરનામું, ખાતું કે પ્રકાશિત ન કરેલી વિનંતીની પેટર્નને તોલી શકે છે. નામ-ઉકેલની નિષ્ફળતા સાઇટ સુધી ક્યારેય પહોંચી જ નહીં, અને સરનામું પ્રથમ ચકાસવાની વસ્તુ છે. ટાઇમઆઉટ બંને વચ્ચે છે: કંઈક મોકલાયું અને કોઈએ તેની પુષ્ટિ કરી નહીં.

પ્રમાણપત્ર ચેતવણીઓ ચોથી શાખાની છે. તેનો અર્થ છે કે જેની ઓળખ બ્રાઉઝર ચકાસી શક્યું નહીં તેવી કોઈ વસ્તુએ જોડાણનો જવાબ આપ્યો, એટલે કે કાં તો તમારી બાજુનો પ્રોક્સી અથવા સાચી અસંગતિ જેને ક્લિક કરીને પાર ન કરવી જોઈએ. આને રૂટિંગનો નહીં, વિશ્વાસનો પ્રશ્ન ગણો.

જવાબ આપતી સાઇટે તૂટેલી ટનલ સાબિત કરી નથી

જ્યારે જવાબ બ્લોક પૃષ્ઠ હોય, ત્યારે બ્રાઉઝર અને મશીન અપરિવર્તિત રાખીને તે જ પૃષ્ઠની બીજા નિકાસ દ્વારા તુલના કરો. જો પરિણામ નિકાસ સરનામાને અનુસરે, તો સાઇટ તે સરનામા સાથે જુદું વર્તન કરે છે, અને કોઈ ક્લાયન્ટ કન્ફિગરેશન તેને બદલશે નહીં. જો અવરોધ તમારા બ્રાઉઝરને અનુસરે, તો કારણ એક્સ્ટેન્શન, સાચવેલા પ્રોક્સી કે રિઝોલ્વર સેટિંગમાં છે. બે રન આ સમજૂતીઓને સસ્તામાં અલગ કરે છે.

ફક્ત બ્રાઉઝરમાં થતી નિષ્ફળતાઓ પૂરતી સામાન્ય છે કે તેને વહેલી ચકાસવી જોઈએ. કોઈ પૃષ્ઠ એક સમર્થિત બ્રાઉઝરમાં લોડ થઈને બીજામાં નિષ્ફળ જાય, તો તે પ્રોફાઇલ સ્થિતિ, સામગ્રી-અવરોધક કે બ્રાઉઝરની અંદર જ ગોઠવાયેલા એન્ક્રિપ્ટેડ DNS તરફ સંકેત કરે છે. Chrome ના સુરક્ષિત DNS અંગેના માર્ગદર્શન સૂચવે છે કે તે સેટિંગ ક્યાં છે, અને તેને સમર્થિત નિયંત્રણથી બદલવું ઉપકરણ રીસેટ કરવા કરતાં સારું છે.

જ્યારે ફક્ત મોટા સ્થાનાંતરણ અટકે, પેકેટનું કદ જુઓ

જે પૃષ્ઠ પોતાનું શીર્ષક દોરે અને પછી અટકી જાય તેની સહી ક્યારેય શરૂ ન થતા પૃષ્ઠ કરતાં જુદી હોય છે. નાના પ્રતિસાદ પસાર થઈ શકે છે જ્યારે પૂરા કદનો પેલોડ ક્યાંક ફેંકાય છે જે મોકલનારને સંકેત આપી શકતું નથી, અને બ્રાઉઝરથી પથ MTU નિષ્ફળતા એવી જ દેખાય છે. ફિલ્ટરિંગ વિશે સિદ્ધાંત બનાવતા પહેલાં એક જ હોસ્ટ પર નાની અને મોટી વિનંતી મોકલીને તુલના કરો. પથ MTU શોધે પથ પરની સૌથી નાની કડીનું કદ શીખવું જોઈએ, અને તે ફિલ્ટર કરેલા નેટવર્ક નિયમિતપણે ફેંકી દેતા ICMP પ્રતિસાદ પર આધાર રાખે છે.

તે પરિકલ્પના એક ping ને બદલે કદ-સ્કેનથી ચકાસો. સ્થિર પેલોડ કદ પર શરૂ થતી નિષ્ફળતા મજબૂત પુરાવો છે, જ્યારે ભટકતી નિષ્ફળતા નથી.

નિષ્ફળ થયેલી વિનંતી પર જ સુધારણાની પુષ્ટિ કરો

મૂળ ક્રિયા ફરી ચકાસો, હોમપેજ નહીં, કારણ કે કેશ કરેલું ખોળિયું દોરાઈ શકે છે જ્યારે સાઇન-ઇન પાછળનો API કૉલ હજી નિષ્ફળ જાય છે. નીચેના આદેશો એક જ હોસ્ટ પર નામ-ઉકેલ, નાની વિનંતી અને મોટી વિનંતી અલગ કરે છે. હોસ્ટનામ અને પથને ખરેખર તૂટેલી વિનંતીના મૂલ્યોથી બદલો.

dig +short www.example.com
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://www.example.com/
curl -sS -o /dev/null -w '%{http_code} %{size_download}\n' https://www.example.com/assets/app.js
ping -M do -s 1400 -c 3 203.0.113.20

જો dig નો જવાબ બ્રાઉઝરે વાપરેલા કરતાં જુદો હોય, તો રિઝોલ્વર ચલ છે, અને બ્રાઉઝરનું પોતાનું DNS સેટિંગ જોવાની જગ્યા છે. જો નાની વિનંતી સ્થિતિ પરત કરે જ્યારે મોટી અટકે, તો પેકેટ-કદ શાખા પર કામ કરો. જો બંને સમય પૂરો કરે, તો નિકાસ પથ અને તે સરનામા પ્રત્યે સાઇટનું વલણ ફરી મેજ પર છે.

જે ફેરફારે મૂળ વિનંતી સફળ કરી તે રાખો અને બાકીનું પાછું ફેરવો. બ્રાઉઝર, રિઝોલ્વર અને ક્લાયન્ટ પર એકસાથે કરેલા ફેરફારોનો ઢગલો તમને કહેવા દેતો નથી કે કયો મહત્ત્વનો હતો.