Squid ലോഗുകൾ: 407 നു ശേഷം 200 വന്നാൽ അത് പരാജയമായി കണക്കാക്കണോ?

ഒരു ക്ലയന്റ് പ്രോക്സി ക്രെഡൻഷ്യലുകളില്ലാതെ ഒരു അഭ്യർത്ഥന അയച്ച്, ചലഞ്ച് സ്വീകരിച്ച്, പിന്നീട് വിജയകരമായി വീണ്ടും ശ്രമിക്കുന്നു എന്ന് കരുതുക. അഭ്യർത്ഥന ലോഗിൽ രണ്ട് എൻട്രികൾ ഉണ്ടാകാം. എന്നാൽ ആപ്പ് ഉപയോഗിക്കുന്ന വ്യക്തി അനുഭവിച്ചത് ഒരു പൂർത്തിയായ പ്രവർത്തനം മാത്രമാണ്.

അതുകൊണ്ടാണ് TCP_DENIED/407 എന്നതിനും TCP_TUNNEL/200 എന്നതിനും ഇടയിൽ തുല്യമായി വിഭജിച്ച ലോഗ് അമ്പത് ശതമാനം പരാജയ നിരക്ക് സ്വയം തെളിയിക്കാത്തത്. ആദ്യം എൻട്രികൾ ചലഞ്ച്-ഉം-വീണ്ടും-ശ്രമവും ജോഡികൾ രൂപപ്പെടുത്തുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുക.

യഥാർത്ഥത്തിൽ നിങ്ങൾക്ക് പ്രധാനമായ കാര്യം എണ്ണുക

സമയ മുദ്രകൾ, ക്ലയന്റ് സന്ദർഭം, ലക്ഷ്യസ്ഥാനം, ലഭ്യമായ ഏതെങ്കിലും അഭ്യർത്ഥന ഐഡന്റിഫയർ എന്നിവ പരസ്പരം ബന്ധിപ്പിക്കുക. പ്രാമാണീകരണമില്ലാത്ത ശ്രമത്തിൽ രേഖപ്പെടുത്തിയ ഉപയോക്തൃനാമം ഉണ്ടാകണമെന്നില്ല, എന്നാൽ അതിന്റെ വിജയകരമായ വീണ്ടും-ശ്രമത്തിൽ ഉണ്ട്. ഒരേസമയത്തുള്ള പ്രവർത്തനം എന്നാൽ അടുത്തടുത്ത വരികൾ മാത്രം രണ്ട് എൻട്രികൾ ഒന്നിച്ചാണെന്നതിന് ദുർബലമായ തെളിവാണ്.

വിജയകരമായ ടണൽ വിജയകരമായ വെബ്സൈറ്റ് പ്രവർത്തനത്തിൽ നിന്ന് വേർതിരിച്ച് സൂക്ഷിക്കുക. CONNECT സ്വീകരിക്കുന്നത് ടണൽ സ്ഥാപിക്കുന്നു; ലക്ഷ്യസ്ഥാനം ഇപ്പോഴും TLS സമയത്ത് പരാജയപ്പെടാം അല്ലെങ്കിൽ പിന്നീട് ആപ്പ് പിശക് നൽകാം.

ആവർത്തിച്ചുള്ള അന്തിമ ചലഞ്ചുകൾ, പിന്നീട് ഒരിക്കലും പൂർത്തിയാകാത്ത ജോലികൾ, അല്ലെങ്കിൽ കൈമാറ്റങ്ങളുടെ എണ്ണത്തിലെ പെട്ടെന്നുള്ള മാറ്റം എന്നിവ അന്വേഷിക്കുക. ഇവ ആദ്യം ചലഞ്ച് സ്വീകരിച്ച് അതിന്റെ കോൺഫിഗറേഷൻ ആവശ്യപ്പെടുന്നത് കൃത്യമായി ചെയ്യുന്ന സ്ഥിരതയുള്ള ക്ലയന്റിൽ നിന്ന് വ്യത്യസ്തമാണ്. ഡാഷ്ബോർഡ് കൂടുതൽ പച്ചയാക്കാൻ വേണ്ടി മാത്രം പ്രാമാണീകരണം അടിച്ചമർത്തുന്നത് അളവ് നന്നാക്കുന്നതിനുപകരം സേവനം തന്നെ മാറ്റും.