ਇੱਕ ਮੰਜ਼ਿਲ ਡੋਮੇਨ ਨੂੰ ਹੋਰ Squid 7 ਪੇਰੈਂਟ ਵੱਲ ਰੂਟ ਕਰੋ

ਮੰਨ ਲਓ ਕਿ ਇੱਕ ਸਾਥੀ ਡੋਮੇਨ ਨੂੰ ਨਿਰਧਾਰਿਤ upstream ਪ੍ਰੌਕਸੀ ਵਰਤਣੀ ਪੈਂਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਹੋਰ ਮਨਜ਼ੂਰ ਬੇਨਤੀਆਂ ਆਮ ਪੇਰੈਂਟ ਵਰਤਦੀਆਂ ਹਨ। Squid 7 ਵਿੱਚ ਨਾਮਿਤ peers ਅਤੇ cache_peer_access ਉਸ ਨੀਤੀ ਨੂੰ ਪ੍ਰਗਟ ਕਰਦੇ ਹਨ:

cache_peer partner-proxy.example parent 3128 0 no-query name=partner_parent
cache_peer general-proxy.example parent 3128 0 no-query name=general_parent

acl partner_domain dstdomain .partner.example

cache_peer_access partner_parent allow partner_domain
cache_peer_access partner_parent deny all

cache_peer_access general_parent deny partner_domain
cache_peer_access general_parent allow all

never_direct allow all

ਇਹ ਮੌਜੂਦਾ, ਪਹੁੰਚ-ਨਿਯੰਤਰਿਤ ਫਾਰਵਰਡ ਪ੍ਰੌਕਸੀ ਲਈ ਰੂਟਿੰਗ ਟੁਕੜਾ ਹੈ। ਜੇ ਸੁਤੰਤਰ ਜਨਤਕ-ਮੰਜ਼ਿਲ ਟੈਸਟ ਬਿਨਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਵਾਲੇ ਜਨਤਕ ਪੇਰੈਂਟ ਵਰਤ ਸਕਦਾ ਹੈ, ਤਾਂ ਉਨ੍ਹਾਂ ਪਤਿਆਂ ਲਈ HTTP ਪ੍ਰੌਕਸੀ ਸੂਚੀ ਵਿੱਚੋਂ ਉਮੀਦਵਾਰ ਚੁਣੋ ਜਿਨ੍ਹਾਂ ਲਈ ਪੇਰੈਂਟ ਪ੍ਰਮਾਣ ਸੈਟ ਨਹੀਂ ਹਨ। ਸਾਥੀ ਦਾ ਲੋੜੀਂਦਾ ਉਤਪਾਦਨ ਮਾਰਗ ਵੱਖਰੀ ਪਹੁੰਚ ਵਿਵਸਥਾ ਰਹਿੰਦਾ ਹੈ। ਨਾਮ ਹਰ ਪੇਰੈਂਟ ਨੂੰ ਉਸ ਦੇ ਪਹੁੰਚ ਨਿਯਮਾਂ ਲਈ ਸਪਸ਼ਟ ਪਛਾਣ ਦਿੰਦੇ ਹਨ।

ਮੇਲ ਖਾਂਦੀ ਮੰਜ਼ਿਲ ਲਈ ਸਿਰਫ਼ partner_parent ਯੋਗ ਰਹਿੰਦਾ ਹੈ। ਹੋਰ ਮੰਜ਼ਿਲਾਂ ਲਈ ਸਿਰਫ਼ general_parent ਯੋਗ ਰਹਿੰਦਾ ਹੈ। ਹਰ ਵਿਅਕਤੀਗਤ peer ਲਈ ਪਹਿਲਾ ਮੇਲ ਖਾਂਦਾ ਨਿਯਮ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਉਹ peer ਯੋਗ ਹੈ ਜਾਂ ਨਹੀਂ।

cache_peer_access ਉਮੀਦਵਾਰਾਂ ਨੂੰ ਫਿਲਟਰ ਕਰਦਾ ਹੈ; ਇਹ ਸਾਰੇ peers ਨੂੰ ਫਾਲਬੈਕ ਚੇਨ ਵਿੱਚ ਨਹੀਂ ਰੱਖਦਾ। ਜੇ ਤੁਸੀਂ ਕਈ ਯੋਗ ਛੱਡਦੇ ਹੋ, ਤਾਂ Squid ਦੇ peer-ਚੋਣ ਐਲਗੋਰਿਦਮ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਚੁਣਦੇ ਹਨ।

never_direct ਲਾਈਨ ਇਸ ਉਦਾਹਰਨ ਵਿੱਚ ਪੇਰੈਂਟ ਦੀ ਵਰਤੋਂ ਲਾਜ਼ਮੀ ਬਣਾਉਂਦੀ ਹੈ। ਜੇ ਲੋੜੀਂਦਾ ਪੇਰੈਂਟ ਵਰਤਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ, ਤਾਂ ਸਿੱਧਾ ਕਨੈਕਸ਼ਨ ਬਦਲ ਵਜੋਂ ਨਹੀਂ ਦਿੱਤਾ ਜਾਂਦਾ। http_access ਵਿੱਚ ਮੌਜੂਦਾ ਕਲਾਇੰਟ ਅਤੇ ਮੰਜ਼ਿਲ ਅਨੁਮਤੀਆਂ ਰੱਖੋ; ਉਹ ਨਿਯਮ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ upstream ਚੋਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿਹੜੀਆਂ ਬੇਨਤੀਆਂ ਸਵੀਕਾਰ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।

ਇਹ ਸੰਰਚਨਾ ਦਸਤਾਵੇਜ਼ੀ Squid 7 ਇੰਟਰਫ਼ੇਸ ਵਰਤਦੀ ਹੈ। ਸੰਦਰਭ cache_peer_access ਨੂੰ Squid 8 ਵਿੱਚ ਉਪਲਬਧ ਨਹੀਂ ਦੱਸਦਾ, ਇਸ ਲਈ ਇਸ ਸੈੱਟਅੱਪ ਦੀ ਸੰਭਾਲ ਕਰਦਿਆਂ ਮੇਲ ਖਾਂਦੇ ਤੈਨਾਤ ਸੰਸਕਰਣ ਦੇ ਦਸਤਾਵੇਜ਼ ਵਰਤੋ।