3proxy ਦੀਆਂ HTTP ਅਤੇ SOCKS ਦੋਵੇਂ ਸੇਵਾਵਾਂ 'ਤੇ ਲੌਗਇਨ ਲਾਜ਼ਮੀ ਕਰੋ

ਵਰਤੋਂਕਾਰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ 3proxy ਦਾ ਪੂਰਾ ਲੌਗਇਨ ਸੰਰਚਨਾ ਨਹੀਂ ਹੈ। ਸੇਵਾ ਨੂੰ ਪਰਮਾਣਿਕਰਨ ਢੰਗ ਅਤੇ ਉਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲਾ ਪਹੁੰਚ ਨਿਯਮ ਵੀ ਚਾਹੀਦਾ ਹੈ। ਕ੍ਰਮ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਸੰਰਚਨਾ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦੌਰਾਨ ਸੇਵਾ ਸੈਟਿੰਗਾਂ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ।

ਦੋ ਸੇਵਾਵਾਂ ਲਈ ਸਿਰਫ਼ ਸਥਾਨਕ ਉਦਾਹਰਨ:

users alex:CL:replace_with_a_private_password
auth strong
allow alex
proxy -i127.0.0.1 -p3128
flush
allow alex
socks -i127.0.0.1 -p1080

ਸੰਰਚਨਾ ਸੰਦਰਭ users, auth strong ਅਤੇ ਸੇਵਾ ਕਮਾਂਡਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ। CL ਇਸ ਉਦਾਹਰਨ ਪਾਸਵਰਡ ਨੂੰ ਸਾਦਾ ਟੈਕਸਟ ਵਜੋਂ ਸੰਭਾਲਦਾ ਹੈ। ਫ਼ਾਈਲ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖੋ ਅਤੇ ਤੈਨਾਤੀ ਲਈ ਢੁਕਵਾਂ ਸਮਰਥਿਤ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਸੰਭਾਲ ਰੂਪ ਚੁਣੋ।

ਕਲਾਇੰਟ ਨੂੰ ਸਹੀ ਲੌਗਇਨ ਅਦਲਾ-ਬਦਲੀ ਚਾਹੀਦੀ ਹੈ

HTTP ਸੇਵਾ HTTP ਪਰਾਕਸੀ ਪਰਮਾਣਿਕਰਨ ਦੀ ਉਮੀਦ ਕਰਦੀ ਹੈ। SOCKS ਸੇਵਾ ਨੂੰ SOCKS5 ਵਰਤੋਂਕਾਰ ਨਾਮ ਅਤੇ ਪਾਸਵਰਡ ਪਰਮਾਣਿਕਰਨ ਦਾ ਸਮਰਥਨ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ ਚਾਹੀਦਾ ਹੈ। SOCKS4 ਕਲਾਇੰਟ ਸਿਰਫ਼ ਇਸ ਲਈ ਉਹ ਅਦਲਾ-ਬਦਲੀ ਨਹੀਂ ਦੇ ਸਕਦਾ ਕਿ ਉਹ ਉਸੇ ਸੁਣਨ ਪੋਰਟ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ।

strong ਸ਼ਬਦ ਪਰਮਾਣਿਕਰਨ ਮੋਡ ਦਾ ਨਾਮ ਹੈ, ਐਨਕ੍ਰਿਪਟਿਡ ਆਵਾਜਾਈ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ। ਲੋੜ ਪੈਣ 'ਤੇ ਕਲਾਇੰਟ ਤੋਂ ਪਰਾਕਸੀ ਤੱਕ ਦਾ ਹਿੱਸਾ ਸੁਰੱਖਿਅਤ ਰੱਖੋ। ਮੰਜ਼ਿਲ ਤੱਕ HTTPS ਅਤੇ ਪਰਾਕਸੀ ਤੱਕ ਐਨਕ੍ਰਿਪਸ਼ਨ ਵੱਖਰੇ ਫ਼ੈਸਲੇ ਰਹਿੰਦੇ ਹਨ।

ਲੂਪਬੈਕ ਬਾਈਂਡਿੰਗ ਇਸ ਉਦਾਹਰਨ ਨੂੰ ਸਥਾਨਕ ਪਹੁੰਚ ਤੱਕ ਸੀਮਤ ਕਰਦੀਆਂ ਹਨ। ਦੂਰ ਦੇ ਕਲਾਇੰਟਾਂ ਲਈ ਇੱਛਤ ਸੁਣਨ ਵਾਲਾ ਅਤੇ ਨੈੱਟਵਰਕ ਨੀਤੀ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਚੁਣੋ। ਜਨਤਕ ਵਾਈਲਡਕਾਰਡ ਸੁਣਨ ਵਾਲਾ ਲੌਗਇਨ ਵਿਵਹਾਰ ਦੀ ਜਾਂਚ ਦਾ ਬਦਲ ਨਹੀਂ ਹੈ।

ਜੇ ਇੱਕ ਸੇਵਾ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਮੰਗਦੀ ਹੈ ਅਤੇ ਦੂਜੀ ਨਹੀਂ, ਤਾਂ ਹਰ ਸੇਵਾ ਕਮਾਂਡ ਤੋਂ ਪਹਿਲਾਂ ਦੀਆਂ ਸੈਟਿੰਗਾਂ, ਕਿਸੇ ਵੀ flush ਤੋਂ ਬਾਅਦ ਦੇ ਨਿਯਮ ਅਤੇ ਪਰਮਾਣਿਕਰਨ ਕੈਸ਼ ਦੀ ਜਾਂਚ ਕਰੋ। ਪਾਸਵਰਡ ਬਦਲਣ ਨਾਲ ਗਲਤ ਨੀਤੀ ਹੇਠ ਸ਼ੁਰੂ ਹੋਈ ਸੇਵਾ ਠੀਕ ਨਹੀਂ ਹੁੰਦੀ। ਇਸੇ ਤਰ੍ਹਾਂ ਡੈਮਨ ਦਾ ਓਪਰੇਟਿੰਗ-ਸਿਸਟਮ ਖਾਤਾ ਬਦਲਣ ਨਾਲ ਪਰਾਕਸੀ ਵਰਤੋਂਕਾਰ ਨਹੀਂ ਬਣਦਾ।