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 ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಪದೇ ಪದೇ ಬದಲಾಯಿಸುವುದಕ್ಕಿಂತ ಪೇರೆಂಟ್ ಪಾತ್ರವನ್ನು ಸರಿಪಡಿಸುವುದು ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟವಾಗಿದೆ.