Squid cache_peer: ഫോർവേഡ് പേരന്റിനെ originserver ആയി അടയാളപ്പെടുത്തരുത്

cache_peer വരി ഒരു പേരന്റിനെ പേരിടാം, എന്നിട്ടും Squid അതിനോട് ഒറിജിൻ വെബ്സൈറ്റ് ആണെന്ന പോലെ സംസാരിക്കാൻ പറയാം.

ഉത്തരവാദിയായ സ്വിച്ച് originserver ആണ്. പേരന്റ് ഒരു വെബ് സെർവർ ആയിരിക്കുന്ന ആക്സിലറേറ്റർ ക്രമീകരണങ്ങൾക്കായി Squid ഇത് രേഖപ്പെടുത്തുന്നു. “യഥാർത്ഥ അഭ്യർത്ഥന ഈ പേരന്റിലൂടെ അയയ്ക്കുക” എന്നർത്ഥമുള്ള പൊതുവായ ഫ്ലാഗ് അല്ല ഇത്.

അടുത്ത ഹോപ്പ് സാധാരണ HTTP ഫോർവേഡ് പ്രോക്സിയാണെങ്കിൽ, ആ ഫ്ലാഗ് അവിടെ ഉൾപ്പെടുന്നതാണോ എന്ന് പരിശോധിക്കുക. അടിസ്ഥാന പേരന്റ് പ്രഖ്യാപനത്തിന് പകരം ഈ രൂപമാണ്:

cache_peer parent.example parent 8080 0 no-query name=upstream

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

proxy-only, ചിലപ്പോൾ originserver-ന് അടുത്ത് പകർത്തപ്പെടുന്നു, ആ പേരന്റിൽ നിന്ന് എടുത്ത വസ്തുക്കൾ സൂക്ഷിക്കുന്നതുമായി ബന്ധപ്പെട്ടതാണ്. രണ്ട് ഫ്ലാഗുകളും ഒരുമിച്ച് നീക്കം ചെയ്യുന്നത് രണ്ടും പ്രോട്ടോക്കോൾ പരാജയത്തിന് കാരണമായി എന്ന് തെളിയിക്കുന്നില്ല.

അടുത്ത സേവനം എന്താണ് പ്രതീക്ഷിക്കുന്നതെന്ന് നോക്കുക: ഒരു വെബ്സൈറ്റ് അഭ്യർത്ഥന, ഒരു ഫോർവേഡ്-പ്രോക്സി അഭ്യർത്ഥന, അല്ലെങ്കിൽ ഒരു ടണൽ സ്ഥാപിക്കൽ കൈമാറ്റം. സാധുവായ ഹോസ്റ്റ്നാമിനും എത്തിച്ചേരാവുന്ന പോർട്ടിനും ആ കരാറുകളെ പരസ്പരം മാറ്റാവുന്നതാക്കാൻ കഴിയില്ല. അഭ്യർത്ഥനയുടെ അർത്ഥം തെറ്റായിരുന്ന ഒരു കണക്ഷനിൽ TLS സർട്ടിഫിക്കറ്റുകൾ ആവർത്തിച്ച് മാറ്റുന്നതിനേക്കാൾ പേരന്റിന്റെ പങ്ക് തിരുത്തുന്നത് കൂടുതൽ കൃത്യമാണ്.