ಪ್ರಾಕ್ಸಿ VIP ಫೇಲೋವರ್ ನಂತರ ಏನು ಉಳಿಯುತ್ತದೆ?
ಪ್ರಾಕ್ಸಿ ಪ್ರವೇಶದ ಪುನಃಪ್ರಾಪ್ತಿಯನ್ನು ಸ್ಥಾಪಿತ CONNECT ಸುರಂಗಗಳ ಮತ್ತು ವೆಬ್ಸೈಟ್ನತ್ತ ಹೋಗುವ ಔಟ್ಬೌಂಡ್ ವಿಳಾಸದ ಉಳಿಕೆಯಿಂದ ಬೇರ್ಪಡಿಸಿ.
ತೇಲುವ ವಿಳಾಸವು ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಸ್ಥಿರವಾಗಿರಿಸುತ್ತದೆ: ಸಕ್ರಿಯ ಯಂತ್ರ ವಿಫಲವಾದ ನಂತರವೂ ಕ್ಲೈಂಟ್ಗಳು ಅದೇ ಹೋಸ್ಟ್ನೇಮ್ ಅಥವಾ IP ಬಳಸುತ್ತವೆ. ಅದು ಉಪಯುಕ್ತ ಲಭ್ಯತೆ. ಆದರೆ ನಡೆಯುತ್ತಿರುವ ಡೌನ್ಲೋಡ್ ನಿಂತುಹೋಗಬಹುದು.
ಈಗಾಗಲೇ CONNECT ಒಳಗಿರುವ HTTPS ವಿನಂತಿಯನ್ನು ಪರಿಗಣಿಸಿ. ಸಕ್ರಿಯ ಪ್ರಾಕ್ಸಿ ಕ್ಲೈಂಟ್ನ ಕಡೆಗಿನ TCP ಸಂಪರ್ಕವನ್ನು ಮತ್ತು ವೆಬ್ಸೈಟ್ನ ಕಡೆಗಿನ ಇನ್ನೊಂದು ಸಂಪರ್ಕವನ್ನು ಹೊಂದಿದೆ. ಆ ಸ್ಟ್ರೀಮ್ಗಳನ್ನು ಬೆಸೆಯುವ ಅಪ್ಲಿಕೇಶನ್ ಸ್ಥಿತಿಯನ್ನೂ ಹೊಂದಿದೆ.
ವಿಳಾಸವನ್ನು ಸ್ಟ್ಯಾಂಡ್ಬೈ ಯಂತ್ರಕ್ಕೆ ಸರಿಸುವುದರಿಂದ ತಾನಾಗಿಯೇ TCP ನಿಯಂತ್ರಣ ಬ್ಲಾಕ್ ಅಥವಾ ಆ ರಿಲೇ ಸ್ಥಿತಿ ಸರಿಯುವುದಿಲ್ಲ. ಹೊಸ ಮಾಲೀಕರು ಹೊಸ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸಬಹುದು, ಆದರೆ ಹಳೆಯ ಮಾಲೀಕರು ಸ್ಥಾಪಿಸಿದ ಬೈಟ್ ಸ್ಟ್ರೀಮ್ ಮುಂದುವರಿಸಲಾಗದು.
| ನಿರೀಕ್ಷೆ | ಸಾಮಾನ್ಯ ವಿಳಾಸ ಫೇಲೋವರ್ ಅದನ್ನು ನೀಡುತ್ತದೆಯೇ? |
|---|---|
| ಒಂದು ಸಂರಚಿತ ಪ್ರವೇಶವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವುದು | ಅದೇ ಉದ್ದೇಶಿತ ಲಾಭ |
| ಸ್ಥಾಪಿತ CONNECT ಸ್ಟ್ರೀಮ್ ಮುಂದುವರಿಸುವುದು | ಹೆಚ್ಚುವರಿ ಸ್ಥಿತಿ-ಆಧಾರಿತ ಯಂತ್ರಾಂಶ ಬೇಕಾಗುತ್ತದೆ |
| ಅದೇ ಔಟ್ಬೌಂಡ್ ಸಾರ್ವಜನಿಕ IP ಉಳಿಸಿಕೊಳ್ಳುವುದು | ಔಟ್ಬೌಂಡ್ ರೂಟಿಂಗ್ ಮತ್ತು NAT ಅನ್ನು ಅವಲಂಬಿಸಿದೆ |
| ಅಡ್ಡಿಪಡಿಸಿದ ಅಪ್ಲಿಕೇಶನ್ ಕ್ರಿಯೆಯನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಪುನರಾವರ್ತಿಸುವುದು | ಕ್ರಿಯೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಅನ್ನು ಅವಲಂಬಿಸಿದೆ |
VRRP ಆಯ್ಕೆ ಮತ್ತು ವಿಳಾಸದ ಮಾಲೀಕತ್ವವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. ಇದು ಪ್ರಾಕ್ಸಿ ಪ್ರಕ್ರಿಯೆಗೆ ಪ್ರತಿಕೃತಿ ಪ್ರೋಟೋಕಾಲ್ ಅಲ್ಲ. ಇನ್ನೊಂದು ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಯ ತಂತ್ರಾಂಶ ಬಳಸುವ ನಿಯೋಜನೆಗೂ ಅದೇ ಭೇದ ಬೇಕು, ಸ್ಪಷ್ಟವಾಗಿ ಹೆಚ್ಚು ನೀಡದಿದ್ದರೆ.
ಆರೋಗ್ಯ ಪರಿಶೀಲನೆ ನಿಜವಾಗಿ ಏನನ್ನು ಗಮನಿಸುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಪ್ರಾಕ್ಸಿ ಸೇವೆ, DNS ಅಥವಾ ಮೇಲ್ಮುಖ ಮಾರ್ಗ ವಿಫಲವಾದರೂ ಯಂತ್ರವು ಪ್ರಕಟಣೆಗಳಿಗೆ ಉತ್ತರಿಸಬಹುದು. ವಿರುದ್ಧವಾಗಿ, ಅತಿ ಸಂವೇದನಶೀಲ ಪರಿಶೀಲನೆಗಳು ಅನಗತ್ಯ ಬದಲಾವಣೆಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು.
ಕ್ಲೈಂಟ್ ಚೇತರಿಕೆಯೂ ಮುಖ್ಯ. ಹೊಸ ಬ್ರೌಸರ್ ವಿನಂತಿ ಸುಲಭವಾಗಿ ಮತ್ತೆ ಸಂಪರ್ಕಗೊಳ್ಳಬಹುದು; ಬಳಸಲಾದ ಬಾಡಿ ಯೊಂದಿಗೆ ಅಪ್ಲೋಡ್ ಅಥವಾ ಐಡೆಂಪೊಟೆಂಟ್ ಅಲ್ಲದ API ಕ್ರಿಯೆಗೆ ಅಪ್ಲಿಕೇಶನ್-ನಿರ್ದಿಷ್ಟ ನಿರ್ವಹಣೆ ಬೇಕಾಗಬಹುದು. ಸ್ಟ್ಯಾಂಡ್ಬೈ ಮೂಲಕ ಹೊಸ ವಿನಂತಿ ಯಶಸ್ವಿಯಾದ ಕಾರಣಕ್ಕೇ ಅಗೋಚರ ಫೇಲೋವರ್ ಭರವಸೆ ನೀಡಬೇಡಿ.