ટૅબ હજી પણ ટનલ મરતાં પહેલાંનું ડૅશબોર્ડ બતાવે છે. સ્થિતિના આંકડા થીજી જાય છે, નાનું સ્પિનર ફરતું રહે છે, અને સરનામાં પટ્ટી હજી પણ એક કલાક પહેલાં ખોલેલી ઍપ વહન કરે છે. તૂટ્યા પછી તમે કંઈ સ્પર્શ કર્યો નથી, તેમ છતાં પાનું કદાચ હજી પણ તેના પોતાના સમયપત્રક મુજબ તેના સર્વર સુધી પહોંચવાનો પ્રયાસ કરી રહ્યું છે. એ જ ભાગ લોકો ચૂકી જાય છે: ફક્ત દેખાતું પાનું અને હજી પણ વિનંતીઓ મોકલતું પાનું બહારથી એકસરખાં દેખાય છે, અને તેમાંથી ફક્ત એક જ નેટવર્ક લૉગમાં દેખાય છે.

પાનું તમારા વિના જે કામ શરૂ કરે છે

ચાર પ્રક્રિયાઓ લોડ થયેલા દસ્તાવેજને વ્યસ્ત રાખે છે. પુનરાવર્તી ટાઇમર દર થોડી સેકન્ડે સ્થિતિ કૉલ ફરી ચલાવી શકે છે. તમે ટૅબ પર પાછા ફર્યા પછી તે ફરી દૃશ્યમાન થાય ત્યારે fetch સક્રિય થઈ શકે છે. WebSocket અથવા સર્વર-મોકલેલ ઘટનાઓ પર બનેલી જીવંત ચેનલ તેના પોતાના બૅકઑફ સમયપત્રક મુજબ ફરી જોડાવાનો પ્રયાસ કરી શકે છે. સાઇટે નોંધાયેલ સર્વિસ વર્કર તમારી સામે કોઈ ટૅબ ન હોય ત્યારે પણ કતારબદ્ધ સિંક માટે જાગી શકે છે.

એમાંથી કોઈને ક્લિકની જરૂર નથી, અને એમાંથી કોઈ દસ્તાવેજને ફરી લોડ કરતું નથી. સરનામાં પટ્ટી, સ્ક્રોલની સ્થિતિ અને રેન્ડર થયેલા મૂલ્યો બધા જ્યાં હતા ત્યાં જ રહે છે. ફક્ત નેટવર્ક બાજુ બદલાય છે: દરેક નવી કોશિશ તે શરૂ થાય તે ક્ષણે લેવાયેલો તાજો નિર્ણય છે.

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

અગાઉનું પાનું લોડ રૂટ કેમ રાખતું નથી

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

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

નિષ્ફળતા નીતિ ક્યાં ઉતરે છે

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

બે વિગતો નક્કી કરે છે કે તમને એમાંથી કયું મળશે. પહેલી છે ક્લાયન્ટ જે અમલીકરણ વ્યાપ્તિને સમર્થન આપે છે: આખા ઉપકરણ માટે બ્લૉક, ટનલ ઍડૅપ્ટર સુધી મર્યાદિત બ્લૉક, અથવા અપવાદો સાથેનો નિયમ સમૂહ. બીજી છે કે ગંતવ્ય તમે પહેલાં સ્થાનિક પ્રિન્ટર, કૅપ્ટિવ પોર્ટલ અથવા સ્ટ્રીમિંગ સેવા માટે ઉમેરેલા અપવાદની અંદર આવે છે કે નહીં.

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

ફેંકી દેવાય તેવા પાના સાથે નિયંત્રિત તપાસ

તમે નિયંત્રિત કરો છો તેવો હોસ્ટ અને એવું પાનું વાપરો જે તેને બોલાવવા સિવાય બીજું કંઈ કરતું નથી, જેથી કોઈ વાસ્તવિક માહિતી રમતમાં ન હોય. ટર્મિનલથી, તૂટતાં પહેલાં અને પછી માર્ગનો નમૂનો લો:

curl -sS --max-time 5 -o /dev/null -w '%{http_code} %{remote_ip}\n' https://probe.example.net/ping

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

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

સર્વર-બાજુનો પુરાવો બ્રાઉઝર જે બતાવે તેના કરતાં વધુ મજબૂત છે. સમયચિહ્ન અને સ્રોત સરનામા સાથેનો વિનંતી લૉગ સાબિત કરે છે કે પૅકેટ પહોંચ્યું. બ્રાઉઝરની એન્ટ્રીઓ કૂકીઝ, ટોકન અને સંપૂર્ણ URL વહન કરી શકે છે, તેથી ફક્ત તમારા પ્રશ્નને જરૂરી ખાનાં રાખો અને બાકીનાં ક્યાંય પેસ્ટ કરતાં પહેલાં છુપાવો.

જવાબ સાથે શું કરવું

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

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

સંબંધિત લેખો