یک تیم داده پنجنفره میخواهد سرورهای آزمایشیاش بستهها را از یک جا دانلود کنند و هر بار از همان آدرس IP به API یک تأمینکننده برسند. یکی از اعضا Squid را در ده دقیقه روی یک VPS کوچک نصب میکند. یک هفته بعد access.log پر از آدرسهایی است که هیچکس آنها را نمیشناسد: پیکربندی از پستی در یک انجمن آمده بود که با http_access allow all تمام میشد و حالا غریبهها ترافیک خود را از IP تیم بیرون میفرستند.
این راهنما Squid را بدون آن اشتباه روی Ubuntu 24.04 نصب میکند. نخست توضیح میدهد Squid چیست، یک درخواست را به چه ترتیبی بررسی میکند و یک سرور چه چیزی میتواند به شما بدهد و چه چیزی نه. پس از آن یک فایل پیکربندی کامل میآید با لیست سفید IP، ورود با نام کاربری و رمز عبور، کش دیسک و تنظیمات هدر، سپس یک پروکسی والد (parent) با cache_peer و در پایان دستورهایی که همه اینها را آزمایش میکنند.
پروکسی Squid چیست؟
Squid یک سرور پروکسی کشکننده و متنباز است. سرور پروکسی از طرف شما درخواست میفرستد و پاسخها را به شما برمیگرداند (سرور پروکسی چیست و چگونه کار میکند؟). Squid معمولاً بهعنوان فوروارد پروکسی اجرا میشود که برای کلاینتهای پشت خودش کار میکند، نه بهعنوان ریورس پروکسی در جلوی یک وبسایت (فوروارد پروکسی و ریورس پروکسی). این نرمافزار HTTP، HTTPS از راه تونلهای CONNECT و FTP را جابهجا میکند و قاعدههای دسترسی، ابزارهای کمکی ورود (helper)، کش و گزارش درخواستها (لاگ) را هم دارد.
پروژه Squid اکنون نسخه پایدار 7.7 را دارد که در 24 اوت 2026 منتشر شد و توسعهدهندگانش فقط از آخرین نسخه پایدار پشتیبانی میکنند. Ubuntu 24.04 نسخه Squid 6.14 را با بسته 6.14-0ubuntu0.24.04.4 در مخزن noble-updates عرضه میکند و وصلههای امنیتی آن از راه بهروزرسانیهای معمول Ubuntu میرسند. این راهنما از همین بسته استفاده میکند.
Squid یک درخواست را چگونه پردازش میکند؟
ترتیب این گامها بیشتر اشتباههای پیکربندی را توضیح میدهد.
- کلاینت به پورت تعیینشده در
http_portوصل میشود؛ در پیکربندی Ubuntu این پورت 3128 است. - Squid سطرهای
http_accessرا از بالا به پایین میخواند. نخستین سطری که همه شرطهایش برقرار باشد تصمیم میگیرد. مستندات http_access میافزاید که اگر هیچ سطری برقرار نباشد، Squid برعکس سطر آخر عمل میکند؛ پس هر فهرست باید باhttp_access deny allتمام شود. - قاعدهای که ورود لازم دارد، نام کاربری و رمز میخواهد. وقتی Squid به شرط
proxy_authبرسد و اطلاعات ورود معتبری در کار نباشد، با407 Proxy Authentication Requiredپاسخ میدهد (روشهای احراز هویت پروکسی). - HTTP ساده در کش جستوجو میشود. نسخه ذخیرهشدهای که هنوز تازه باشد یک «hit» است و درخواست هرگز از سرور بیرون نمیرود؛ هر حالت دیگر «miss» است و پاسخ از سایت گرفته میشود.
- HTTPS به تونل تبدیل میشود. پس از موفقیت
CONNECT example.com:443، Squid فقط بایتهای رمزگذاریشده را جابهجا میکند. RFC 9110 این کار را «ارسال کورکورانه داده» (blind forwarding of data) مینامد؛ پس Squid نه میتواند صفحه را کش کند و نه درون تونل هدری بیفزاید. - اگر با
cache_peerوnever_directپروکسی والدی تعیین کرده باشید، درخواست به آن سپرده میشود. - Squid یک سطر در
access.logمینویسد که کلاینت، کد نتیجه، اندازه، URL و نام کاربری را در بر دارد.
سرور Squid خودتان چه چیزی به شما میدهد و چه چیزی نه؟
| پرسش | Squid خودتان (یک VPS) | پروکسی دیتاسنتر تجاری | استخر مسکونی یا چرخشی |
|---|---|---|---|
| IP خروجی | تنها IP مرکز داده همان VPS | IPهای مرکز داده ارائهدهنده، در صورت نیاز چندتا | IPهای اینترنت خانگی، برای هر درخواست یا هر نشست |
| موقعیت | شهری که سرور در آن کار میکند | انتخاب از میان کشورهای ارائهدهنده | یک کشور، گاهی یک شهر |
| نگهداری | خودتان: بهروزرسانیها، قاعدهها، رمزها، لاگها | ارائهدهنده؛ شما اطلاعات ورود را مدیریت میکنید | ارائهدهنده؛ شما اطلاعات ورود را مدیریت میکنید |
| کش و کنترل دسترسی | کش HTTP، قاعدهها، یک لاگ مرکزی | بدون کش؛ کاربران در پنل | بدون کش؛ کاربران در پنل |
Squid به شما اختیار میدهد که چه کسی وصل شود، چه چیزی کش شود و چه چیزی در لاگ ثبت شود. اما آدرس دومی به شما نمیدهد: سایتی که در هر دقیقه صدها درخواست از همان یک IP مرکز داده ببیند، سرعت آن را کم میکند یا مسدودش میکند (تفاوت پروکسی مسکونی و دیتاسنتر).
چگونه Squid را روی Ubuntu 24.04 نصب کنید؟
بسته apache2-utils ابزار htpasswd را برای ساختن فایل رمزها اضافه میکند. نگه داشتن یک نسخه فقطخواندنی از پیکربندی اصلی، توصیه راهنمای رسمی Ubuntu Server است.
sudo apt update
sudo apt install squid apache2-utils
squid -v | head -n 1 # the installed version
systemctl status squid --no-pager # should say "active (running)"
sudo cp /etc/squid/squid.conf /etc/squid/squid.conf.original
sudo chmod a-w /etc/squid/squid.conf.original
# where will your own rules be read?
grep -n "include /etc/squid/conf.d" /etc/squid/squid.conf
grep -n "^http_access deny all" /etc/squid/squid.confتنظیمات خود را در فایلی زیر /etc/squid/conf.d/ بگذارید تا ارتقای بسته به آنها دست نزند. بستهبندی Debian که Ubuntu بر پایه آن ساخته شده، سطر include /etc/squid/conf.d/*.conf را زیر توضیح INSERT YOUR OWN RULE(S) HERE قرار میدهد: پس از قاعدههایی که پورتهای ناامن را مسدود میکنند و پیش از http_access allow localhost و http_access deny all. شماره سطر include در خروجی grep باید از شماره سطر deny all کوچکتر باشد؛ اگر نیست، سطرهای خود را در همان جای توضیح، مستقیم در squid.conf بنویسید. فایل debian.conf در همین پوشه مقدار logfile_rotate 0 را تنظیم میکند، چون چرخش لاگها را logrotate انجام میدهد.
فایل کامل team.conf برای پروکسی با دسترسی محدود
این فایل را با نام /etc/squid/conf.d/team.conf ذخیره کنید. شبکه نمونه مستندات، یعنی 203.0.113.0/24، را با شبکه دفتر یا IPهای ثابت تیم خود جایگزین کنید.
# /etc/squid/conf.d/team.conf
# Read inside the http_access list of squid.conf, above "http_access deny all".
# Never add "http_access allow all": it turns this server into an open proxy.
# 1. Which networks may connect
acl team_net src 203.0.113.0/24
# 2. Username and password from /etc/squid/passwords.
# Keep the auth_param lines above the proxy_auth ACL.
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwords
auth_param basic children 5 startup=5 idle=1
auth_param basic realm Team proxy
auth_param basic credentialsttl 2 hours
acl team_users proxy_auth REQUIRED
# 3. Allow only when BOTH match: the right network AND a valid login.
# Everything else falls through to "http_access deny all".
http_access allow team_net team_users
# 4. Do not pass client addresses in plain HTTP requests
forwarded_for delete
via off
# 5. Cache: memory, largest object to store, then the disk cache
cache_mem 512 MB
maximum_object_size 512 MB
cache_dir ufs /var/spool/squid 10000 16 256سپس کاربران را اضافه کنید، درستی نگارش پیکربندی را بررسی کنید، سرویس را یک بار راهاندازی مجدد کنید و پورت را فقط برای آدرسهای شناختهشده باز کنید:
sudo htpasswd -c /etc/squid/passwords team1 # -c creates the file: first user only
sudo htpasswd /etc/squid/passwords team2 # later users: without -c
sudo chown root:proxy /etc/squid/passwords
sudo chmod 640 /etc/squid/passwords
sudo squid -k parse # prints errors and warnings, if any
sudo systemctl restart squid # once, for the new cache_dir
sudo tail -n 20 /var/log/squid/cache.log # startup messages
sudo ufw allow OpenSSH # keep your SSH session reachable
sudo ufw allow from 203.0.113.0/24 to any port 3128 proto tcp
sudo ufw enableقاعدههای acl و http_access را چگونه بنویسید؟
سطر acl به یک شرط نام میدهد؛ سطر http_access این نامها را در یک تصمیم کنار هم میگذارد. همه شرطهای یک سطر باید برقرار باشند، پس allow team_net team_users یعنی «از شبکه ما و با ورود معتبر». سطرهای جداگانه گزینههای جایگزیناند: برای دفتر دوم، acl office2 src 198.51.100.0/24 و http_access allow office2 team_users را اضافه کنید.
جای هر سطر به اندازه محتوای آن مهم است. Squid هرگز به سطر allow که زیر http_access deny all باشد نمیرسد و همه کلاینتها 403 میگیرند. به قاعدههای بالای سطر include دست نزنید: deny CONNECT !SSL_ports اجازه میدهد تونلها فقط به پورت 443 برسند. RFC 9110 توصیه میکند CONNECT به پورتهای شناختهشده محدود شود، چون از پروکسیای که به هر پورتی تونل بزند میتوان برای رساندن هرزنامه به پورت 25 استفاده کرد.
برای تغییر پورت، بهجای افزودن سطر دوم، همان سطر http_port 3128 در squid.conf را ویرایش کنید و فایروال را هم بهروز کنید. پورت تازه از چیزی محافظت نمیکند؛ این کار را ACL و فایروال انجام میدهند. معنای 3128 و 8080 را در پورت 8080 و دیگر پورتهای پروکسی آوردهایم.
چگونه نام کاربری و رمز عبور اضافه کنید؟
htpasswd برای هر کاربر یک سطر با رمز هششده ذخیره میکند. هش پیشفرض آن MD5 است که ابزار کمکی basic_ncsa_auth در Squid آن را میخواند؛ این ابزار در Ubuntu در مسیر /usr/lib/squid/basic_ncsa_auth قرار دارد. این ابزار با کاربر proxy اجرا میشود و به همین دلیل گروه فایل رمزها proxy است. سطرهای auth_param حداکثر پنج نمونه از این ابزار را راه میاندازند، متن پنجره ورود را تعیین میکنند و اجازه میدهند Squid تا دو ساعت به یک ورود درست اعتماد کند و پس از آن دوباره فایل را بررسی کند.
مستندات auth_param در Squid میگوید از کلاینت فقط وقتی اطلاعات ورود خواسته میشود که یک قاعده http_access یک ACL از نوع proxy_auth را بسنجد. اگر auth_param را تنظیم کنید اما team_users را در http_access به کار نبرید، Squid هرگز رمز نمیخواهد.
احراز هویت basic رمز را در هر هدر Proxy-Authorization میان کلاینت و Squid با کدگذاری Base64 میفرستد، نه به شکل رمزگذاریشده. هر کسی که این مسیر را زیر نظر داشته باشد میتواند آن را بخواند و به همین دلیل لیست سفید IP در کنار رمز میماند. خواندن پاسخ 407 را در روشهای احراز هویت پروکسی توضیح دادهایم.
کش را چگونه تنظیم کنید و لاگها را چگونه بخوانید؟
cache_mem حافظهای را که برای اشیای پرتقاضا کنار گذاشته میشود تعیین میکند (پیشفرض 256 مگابایت). cache_dir ufs /var/spool/squid 10000 16 256 حداکثر 10,000 مگابایت کش دیسک در 16 پوشه سطح اول و 256 پوشه سطح دوم میسازد؛ مستندات Squid هشدار میدهد که کل اندازه دیسک را وارد نکنید. مقدار پیشفرض maximum_object_size برابر 4 مگابایت است و فایلهای بزرگتر بستهها را بیرون از کش نگه میدارد، پس آن را بالا ببرید. این دستور حد پیشفرض اندازه را برای هر cache_dir تعیین میکند و به همین دلیل فایل بالا آن را پیش از cache_dir آورده است.
squid -z پوشههای کش را میسازد و فایل سرویس Ubuntu پیش از هر بار اجرا squid --foreground -z را اجرا میکند، پس راهاندازی مجدد این پوشهها را میسازد. برای تغییرهای بعدی در قاعدهها یا کاربران، sudo systemctl reload squid همان سیگنال squid -k reconfigure را میفرستد.
کش فقط به HTTP ساده کمک میکند. آینههای (mirror) Ubuntu معمولاً آدرسهای http:// دارند و apt امضای بستهها را بررسی میکند، پس وقتی ماشینهای CI از راه Squid بسته دریافت کنند، هر بسته فقط یک بار دانلود میشود (تنظیمات پروکسی در Linux). HTTPS هرگز hit نمیدهد. باز کردن آن برای کش (SSL bump) به گواهی Squid روی همه کلاینتها و بسته جداگانه squid-openssl نیاز دارد و از دامنه این راهنما بیرون است.
/var/log/squid/access.log برای هر درخواست یک سطر دارد و cache.log پیامهای راهاندازی و خطاها را نگه میدارد؛ logrotate هر دو را روزانه میچرخاند و دو نسخه قدیمی را نگه میدارد. کد نتیجه نشان میدهد چه اتفاقی افتاده است:
| کد نتیجه | معنا |
|---|---|
TCP_MISS/200 | از سایت دریافت شد |
TCP_HIT/200، TCP_MEM_HIT/200 | از کش دیسک یا کش حافظه داده شد |
TCP_TUNNEL/200 | تونل HTTPS؛ Squid فقط میزبان و پورت را دید |
TCP_DENIED/407 | ورود انجام نشده یا نادرست است |
TCP_DENIED/403 | http_access آن را رد کرد: شبکه نادرست یا ترتیب نادرست قاعدهها |
هدرهای Via و X-Forwarded-For را چگونه حذف کنید؟
Squid بهطور پیشفرض IP کلاینت را به X-Forwarded-For میافزاید (forwarded_for on) و یک هدر Via اضافه میکند (via on). forwarded_for delete این هدر را حذف میکند، off بهجای آدرس unknown مینویسد و via off هدر Via را کنار میگذارد. هر دو فقط روی HTTP ساده کار میکنند؛ درون تونل Squid در هر حال چیزی اضافه نمیکند. برای بررسی نتیجه با یک درخواست echo، سطحهای ناشناسی پروکسی را ببینید.
یک خروجی برای کل تیم: cache_peer با پروکسی والد
تیمی که از پروکسی تجاری استفاده میکند شاید نخواهد رمز آن روی همه لپتاپها و کارهای CI باشد. Squid میتواند در میانه بنشیند: افراد با حسابهای خودشان وارد Squid میشوند و فقط سرور اطلاعات ورود پروکسی تجاری را میداند. این سطرها را به team.conf اضافه کنید:
# Send every request through the parent proxy. Clients never see its password.
cache_peer pr.proxynet.io parent 8000 0 no-query default login=user:pass
never_direct allow allطبق مستندات cache_peer: میزبان، نوع parent، پورت پروکسی 8000 و پورت ICP برابر 0، چون این همتا (peer) به پرسشهای ICP پاسخ نمیدهد. no-query این پرسشها را خاموش میکند، default آن را والدی قرار میدهد که وقتی گزینه دیگری نباشد به کار میرود و login= اطلاعات ورود والد را میفرستد؛ نویسه % را در رمز به شکل %% بنویسید.
بدون never_direct allow all، Squid ممکن است برخی درخواستها را مستقیم از IP خود VPS دریافت کند. برای HTTPS، Squid درخواست CONNECT را به والد میسپارد. در این حالت فیلد سلسلهمراتب (hierarchy) در access.log والد را با کدی مانند DEFAULT_PARENT نشان میدهد، نه HIER_DIRECT.
اکنون تغییر رمز یعنی ویرایش یک سطر و یک reload، هر درخواست با نام کاربری عضو تیم ثبت میشود و HTTP ساده همچنان کش میشود. اگر یک پروکسی چرخشی والد باشد، ارائهدهنده IP خروجی را عوض میکند و Squid برای کلاینتها همان یک آدرس میماند (چرخش IP چیست). این زنجیره اطلاعات ورود را مدیریت میکند؛ هویت شما را پنهان نمیکند و شرایط ارائهدهنده و قاعدههای هر سایت همچنان برقرارند.
کلاینت را چگونه وصل و آزمایش کنید؟
این دستورها را از ماشینی در شبکه مجاز اجرا کنید؛ 198.51.100.20 جای سرور شماست.
# 1. Without a login: Squid asks for one
curl -x http://198.51.100.20:3128 https://httpbin.org/ip
# curl: (7) CONNECT tunnel failed, response 407
# 2. With a login: the answer shows the server's IP, not yours
curl -x http://team1:pass@198.51.100.20:3128 --retry 3 https://httpbin.org/ip
# 3. On the server: the last three requests
sudo tail -n 3 /var/log/squid/access.logبخش curl را با curl 8.21 روی یک پروکسی آزمایشی محلی که ورود لازم دارد اجرا کردیم: دستور اول همان سطر بالا را چاپ کرد و دستور دوم آدرس خروجی پروکسی را برگرداند. --retry 3 پس از پایان مهلت (timeout) یا یک کد HTTP گذرا مانند 429 یا 503 دوباره تلاش میکند، اما هرگز پس از 407. جزئیات بیشتر در استفاده از cURL با پروکسی و آزمایش پروکسی آمده است.
سرور پروکسی خودتان به چه کاری میآید؟
- IP خروجی ثابت برای یک API: فقط ترافیک API از Squid میگذرد (IP ثابت برای API).
- کنترل دسترسی وب در دفتر: ACLهای
dstdomainوaccess.log، به شرط آنکه کارکنان از پیش آگاه شده باشند (پروکسی و فایروال). - تنظیمات مرورگر در دفتر: یک فایل PAC به هر مرورگر میگوید چه زمانی از Squid استفاده کند (فایل PAC).
- کش بسته برای ماشینهای CI: apt هر بسته HTTP ساده را فقط یک بار دریافت میکند (تنظیمات پروکسی در Linux).
- نه برای کار داده در چند کشور: بررسی قیمت و اسکرپینگ بر اساس موقعیت به آدرسهای زیاد نیاز دارد (استخراج داده).
اشتباههای رایج
http_access allow all. پروکسی باز میسازد و IP آن بهزودی در لیستهای سیاه قرار میگیرد (لیست سیاه IP).auth_paramبدونproxy_authدرhttp_access. هیچوقت رمزی خواسته نمیشود.- سطر
allowزیرdeny all. Squid هرگز به آن نمیرسد؛ همه403میگیرند. - پورت 3128 باز به روی اینترنت. رمز بهتنهایی راه را برای حدس زدن باز میگذارد و احراز هویت basic آن را بدون رمزگذاری میفرستد.
- انتظار hit کش برای HTTPS. تونلها هرگز کش نمیشوند.
- اجرا نکردن
squid -k parse. یک غلط تایپی سرویس را متوقف میکند؛journalctl -u squidدلیلش را نشان میدهد. - رها کردن
maximum_object_sizeروی 4 مگابایت برای کش بستهها، یا تعیینcache_dirبزرگتر از فضای آزاد دیسک. - اسکرپینگ سنگین از IP همان VPS. سایتها نخست
429برمیگردانند و سپس مسدود میکنند (کدهای وضعیت HTTP در وب اسکرپینگ).
راهنمای انتخاب
| نیاز | پیشنهاد |
|---|---|
| تیم باید از یک IP به یک API برسد | Squid روی VPS با IP ثابت همراه با لیست سفید و ورود با رمز، یا یک پروکسی استاتیک |
| ماشینهای CI بستههای یکسان را بارها دانلود میکنند | Squid با cache_dir و maximum_object_size بزرگتر؛ صرفهجویی از آینههای HTTP میآید |
| دفتر میخواهد سایتهای بازدیدشده را ببیند و محدود کند | ACLهای dstdomain و access.log؛ نخست کارکنان را آگاه کنید |
| رمز پروکسی تجاری باید فقط روی یک سرور بماند | Squid برای کلاینتها، cache_peer به سوی ارائهدهنده، never_direct allow all |
| به IP در کشورهای دیگر یا IPهای زیاد نیاز دارید | نه Squid خودتان: پروکسی دیتاسنتر، یا استخر مسکونی و چرخشی |
| میخواهید صفحههای HTTPS کش شوند | نه با بسته پیشفرض؛ فقط منابع HTTP ساده را کش کنید |
پرسشهای متداول
Squid از کدام پورت استفاده میکند؟
پیکربندی Ubuntu مقدار http_port 3128 را تنظیم میکند، پس Squid پس از نصب روی 3128 گوش میدهد. میتوانید این سطر و قاعده فایروال را با هم تغییر دهید، اما پورت دیگر هیچ محافظتی نمیافزاید؛ محافظت از ACL شبکه، ورود با رمز و فایروال میآید. معنای شمارهپورتهای رایج پروکسی را در راهنمای پورت 8080 توضیح دادهایم.
آیا Squid میتواند سایتهای HTTPS را کش کند؟
نه با تنظیمات پیشفرض. درخواست HTTPS به شکل تونل CONNECT میرسد و Squid بایتهای رمزگذاریشده را بدون دیدن صفحه جابهجا میکند، پس چیزی برای ذخیره کردن نیست. SSL bump که ترافیک را باز میکند، به گواهی Squid روی همه دستگاههای کلاینت و بسته squid-openssl نیاز دارد و از دامنه این راهنما بیرون است.
تغییرهای squid.conf را چگونه بدون توقف سرویس اعمال کنم؟
نخست sudo squid -k parse را اجرا کنید تا یک غلط تایپی نتواند پروکسی را از کار بیندازد. سپس sudo systemctl reload squid را اجرا کنید که همان سیگنال squid -k reconfigure را میفرستد و سرویس را در حال اجرا نگه میدارد. پس از افزودن یا جابهجا کردن یک cache_dir، بهجای reload یک بار سرویس را راهاندازی مجدد کنید تا پوشههای کش ساخته شوند.
لاگهای Squid کجا هستند و چگونه آنها را بخوانم؟
در Ubuntu این لاگها در /var/log/squid/ هستند: access.log برای هر درخواست یک سطر دارد و cache.log پیامهای راهاندازی و خطاها را. در access.log کد نتیجه را بخوانید: TCP_HIT از کش آمده، TCP_MISS از سایت، TCP_TUNNEL یعنی HTTPS و TCP_DENIED همراه با 407 یا 403 یعنی درخواست رد شده است.
تفاوت Squid و Tinyproxy چیست؟
Tinyproxy خود را یک سرویس پسزمینه (daemon) سبک برای پروکسی HTTP و HTTPS معرفی میکند که برای سیستمهایی ساخته شده است که برای یک پروکسی کامل بیش از حد کوچکاند و در راهنمای پیکربندی آن هیچ تنظیمی برای کش نیامده است. Squid کش حافظه و دیسک، ACLهای دقیق، چند ابزار کمکی ورود و زنجیره پروکسی والد را به اینها میافزاید. برای ارسال ساده درخواستها روی یک دستگاه کوچک، Tinyproxy ممکن است کافی باشد.
آیا سرور Squid خودم هویتم را پنهان میکند؟
فقط تا حدی. سایتها بهجای آدرس خانه شما IP همان VPS را میبینند و forwarded_for delete همراه با via off هدرهای پروکسی را از HTTP ساده حذف میکند. اما آن IP به یک مرکز داده تعلق دارد، به نام شما اجاره شده است و همیشه از یک جا میآید. Squid ابزاری برای کنترل دسترسی و یک خروجی مشترک است، نه برای ناشناس ماندن.
خلاصه
Squid یک فوروارد پروکسی مخصوص خودتان به شما میدهد، با کنترل دسترسی، کش برای HTTP ساده و یک لاگ برای همه درخواستها. یک راهاندازی امن سه چیز را به ترتیب نگه میدارد: یک ACL شبکه، ورود با proxy_auth که در http_access به کار رفته باشد و http_access deny all در پایان، همراه با فایروالی که فقط برای آدرسهای شناختهشده باز است. محدودیت در آدرس است: یک سرور یعنی یک IP مرکز داده در یک مکان. وقتی کاری به آدرسهای بیشتر یا کشورهای دیگر نیاز دارد، یک پروکسی دیتاسنتر یا یک پروکسی مسکونی این کمبود را پر میکند و صفحه خدمات پروکسی ما گزینهها را با هم مقایسه میکند.




