--- title: "پروکسی Squid در ⁦Ubuntu 24.04⁩: نصب، احراز هویت و squid.conf" description: "Squid فوروارد پروکسی متن‌باز است و درخواست‌ها را از IP خودش می‌فرستد. روی ⁦Ubuntu 24.04⁩ نصبش کنید، با ACL و رمز عبور ایمنش کنید و کش را تنظیم کنید." url: https://proxynet.io/fa/blog/squid-proxy-setup date: 2026-09-24 author: "Acar Diveroli" category: "آموزش‌ها, مبانی پروکسی" lang: fa --- # پروکسی Squid در ⁦Ubuntu 24.04⁩: نصب، احراز هویت و squid.conf یک تیم داده پنج‌نفره می‌خواهد سرورهای آزمایشی‌اش بسته‌ها را از یک جا دانلود کنند و هر بار از همان آدرس IP به API یک تأمین‌کننده برسند. یکی از اعضا Squid را در ده دقیقه روی یک VPS کوچک نصب می‌کند. یک هفته بعد `access.log` پر از آدرس‌هایی است که هیچ‌کس آن‌ها را نمی‌شناسد: پیکربندی از پستی در یک انجمن آمده بود که با `http_access allow all` تمام می‌شد و حالا غریبه‌ها ترافیک خود را از IP تیم بیرون می‌فرستند. این راهنما Squid را بدون آن اشتباه روی ⁦Ubuntu 24.04⁩ نصب می‌کند. نخست توضیح می‌دهد Squid چیست، یک درخواست را به چه ترتیبی بررسی می‌کند و یک سرور چه چیزی می‌تواند به شما بدهد و چه چیزی نه. پس از آن یک فایل پیکربندی کامل می‌آید با لیست سفید IP، ورود با نام کاربری و رمز عبور، کش دیسک و تنظیمات هدر، سپس یک پروکسی والد (parent) با `cache_peer` و در پایان دستورهایی که همه این‌ها را آزمایش می‌کنند. > **نکته: پاسخ کوتاه** > > Squid یک فوروارد پروکسی متن‌باز است: درخواست‌های کلاینت‌های شما را از آدرس IP خودش به سایت مقصد می‌فرستد و می‌تواند پاسخ‌های HTTP ساده (بدون رمزگذاری) را کش کند. روی ⁦Ubuntu 24.04⁩ آن را با `sudo apt install squid` نصب می‌کنید؛ روی پورت 3128 گوش می‌دهد و `/etc/squid/squid.conf` را می‌خواند. با تنظیمات پیش‌فرض فقط درخواست‌هایی را می‌پذیرد که از خود سرور بیایند. برای استفاده از ماشین‌های دیگر، یک لیست سفید IP و یک نام کاربری و رمز عبور اضافه کنید و `http_access deny all` را آخرین قاعده نگه دارید. یک سرور یعنی یک IP مرکز داده در یک موقعیت، پس کارهایی که به کشورهای دیگر یا آدرس‌های زیاد نیاز دارند یک پروکسی تجاری لازم دارند. ## پروکسی Squid چیست؟ Squid یک سرور پروکسی کش‌کننده و متن‌باز است. سرور پروکسی از طرف شما درخواست می‌فرستد و پاسخ‌ها را به شما برمی‌گرداند ([سرور پروکسی چیست و چگونه کار می‌کند؟](/fa/blog/what-is-a-proxy-server)). Squid معمولاً به‌عنوان فوروارد پروکسی اجرا می‌شود که برای کلاینت‌های پشت خودش کار می‌کند، نه به‌عنوان ریورس پروکسی در جلوی یک وب‌سایت ([فوروارد پروکسی و ریورس پروکسی](/fa/blog/forward-vs-reverse-proxy)). این نرم‌افزار HTTP، HTTPS از راه تونل‌های `CONNECT` و FTP را جابه‌جا می‌کند و قاعده‌های دسترسی، ابزارهای کمکی ورود (helper)، کش و گزارش درخواست‌ها (لاگ) را هم دارد. پروژه Squid اکنون نسخه پایدار 7.7 را دارد که در 24 اوت 2026 منتشر شد و توسعه‌دهندگانش فقط از آخرین نسخه پایدار پشتیبانی می‌کنند. ⁦Ubuntu 24.04⁩ نسخه ⁦Squid 6.14⁩ را با بسته `6.14-0ubuntu0.24.04.4` در مخزن [noble-updates](https://packages.ubuntu.com/noble-updates/squid) عرضه می‌کند و وصله‌های امنیتی آن از راه به‌روزرسانی‌های معمول Ubuntu می‌رسند. این راهنما از همین بسته استفاده می‌کند. ## Squid یک درخواست را چگونه پردازش می‌کند؟ ترتیب این گام‌ها بیشتر اشتباه‌های پیکربندی را توضیح می‌دهد. 1. **کلاینت به پورت تعیین‌شده در `http_port` وصل می‌شود**؛ در پیکربندی Ubuntu این پورت 3128 است. 2. **Squid سطرهای `http_access` را از بالا به پایین می‌خواند.** نخستین سطری که همه شرط‌هایش برقرار باشد تصمیم می‌گیرد. [مستندات http_access](https://www.squid-cache.org/Doc/config/http_access/) می‌افزاید که اگر هیچ سطری برقرار نباشد، Squid برعکس سطر آخر عمل می‌کند؛ پس هر فهرست باید با `http_access deny all` تمام شود. 3. **قاعده‌ای که ورود لازم دارد، نام کاربری و رمز می‌خواهد.** وقتی Squid به شرط `proxy_auth` برسد و اطلاعات ورود معتبری در کار نباشد، با `407 Proxy Authentication Required` پاسخ می‌دهد ([روش‌های احراز هویت پروکسی](/fa/blog/proxy-authentication-methods)). 4. **HTTP ساده در کش جست‌وجو می‌شود.** نسخه ذخیره‌شده‌ای که هنوز تازه باشد یک «hit» است و درخواست هرگز از سرور بیرون نمی‌رود؛ هر حالت دیگر «miss» است و پاسخ از سایت گرفته می‌شود. 5. **HTTPS به تونل تبدیل می‌شود.** پس از موفقیت `CONNECT example.com:443`، Squid فقط بایت‌های رمزگذاری‌شده را جابه‌جا می‌کند. [⁦RFC 9110⁩](https://www.rfc-editor.org/rfc/rfc9110.html#name-connect) این کار را «ارسال کورکورانه داده» (blind forwarding of data) می‌نامد؛ پس Squid نه می‌تواند صفحه را کش کند و نه درون تونل هدری بیفزاید. 6. **اگر با `cache_peer` و `never_direct` پروکسی والدی تعیین کرده باشید**، درخواست به آن سپرده می‌شود. 7. **Squid یک سطر در `access.log` می‌نویسد** که کلاینت، کد نتیجه، اندازه، URL و نام کاربری را در بر دارد. ## سرور Squid خودتان چه چیزی به شما می‌دهد و چه چیزی نه؟ | پرسش | Squid خودتان (یک VPS) | پروکسی دیتاسنتر تجاری | استخر مسکونی یا چرخشی | |---|---|---|---| | IP خروجی | تنها IP مرکز داده همان VPS | IPهای مرکز داده ارائه‌دهنده، در صورت نیاز چندتا | IPهای اینترنت خانگی، برای هر درخواست یا هر نشست | | موقعیت | شهری که سرور در آن کار می‌کند | انتخاب از میان کشورهای ارائه‌دهنده | یک کشور، گاهی یک شهر | | نگه‌داری | خودتان: به‌روزرسانی‌ها، قاعده‌ها، رمزها، لاگ‌ها | ارائه‌دهنده؛ شما اطلاعات ورود را مدیریت می‌کنید | ارائه‌دهنده؛ شما اطلاعات ورود را مدیریت می‌کنید | | کش و کنترل دسترسی | کش HTTP، قاعده‌ها، یک لاگ مرکزی | بدون کش؛ کاربران در پنل | بدون کش؛ کاربران در پنل | Squid به شما اختیار می‌دهد که چه کسی وصل شود، چه چیزی کش شود و چه چیزی در لاگ ثبت شود. اما آدرس دومی به شما نمی‌دهد: سایتی که در هر دقیقه صدها درخواست از همان یک IP مرکز داده ببیند، سرعت آن را کم می‌کند یا مسدودش می‌کند ([تفاوت پروکسی مسکونی و دیتاسنتر](/fa/blog/residential-vs-datacenter-proxy)). ## چگونه Squid را روی ⁦Ubuntu 24.04⁩ نصب کنید؟ بسته `apache2-utils` ابزار `htpasswd` را برای ساختن فایل رمزها اضافه می‌کند. نگه داشتن یک نسخه فقط‌خواندنی از پیکربندی اصلی، توصیه [راهنمای رسمی Ubuntu Server](https://ubuntu.com/server/docs/how-to/web-services/install-a-squid-server/) است. ```bash 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های ثابت تیم خود جایگزین کنید. ```text # /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 ``` سپس کاربران را اضافه کنید، درستی نگارش پیکربندی را بررسی کنید، سرویس را یک بار راه‌اندازی مجدد کنید و پورت را فقط برای آدرس‌های شناخته‌شده باز کنید: ```bash 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 ``` > **هشدار: پروکسی باز نسازید** > > اسکنرها اینترنت را برای یافتن پروکسی‌هایی که هر آدرسی را می‌پذیرند جست‌وجو می‌کنند و هرزنامه، حمله و اسکرپینگی که از پروکسی شما فرستاده شود به IP شما می‌رسد. ACL شبکه، ورود با رمز و `deny all` پایانی را با هم نگه دارید و 3128 را فقط برای آدرس‌های شناخته‌شده باز کنید ([امنیت پروکسی‌های رایگان](/fa/blog/are-free-proxies-safe)). ## قاعده‌های 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 و دیگر پورت‌های پروکسی](/fa/blog/port-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` را در [روش‌های احراز هویت پروکسی](/fa/blog/proxy-authentication-methods) توضیح داده‌ایم. ## کش را چگونه تنظیم کنید و لاگ‌ها را چگونه بخوانید؟ `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](/fa/blog/linux-proxy-settings)). 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، [سطح‌های ناشناسی پروکسی](/fa/blog/anonymous-proxy-levels) را ببینید. ## یک خروجی برای کل تیم: cache_peer با پروکسی والد تیمی که از پروکسی تجاری استفاده می‌کند شاید نخواهد رمز آن روی همه لپ‌تاپ‌ها و کارهای CI باشد. Squid می‌تواند در میانه بنشیند: افراد با حساب‌های خودشان وارد Squid می‌شوند و فقط سرور اطلاعات ورود پروکسی تجاری را می‌داند. این سطرها را به `team.conf` اضافه کنید: ```text # 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](https://www.squid-cache.org/Doc/config/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 ساده همچنان کش می‌شود. اگر یک [پروکسی چرخشی](https://proxynet.io/fa/rotating-proxy) والد باشد، ارائه‌دهنده IP خروجی را عوض می‌کند و Squid برای کلاینت‌ها همان یک آدرس می‌ماند ([چرخش IP چیست](/fa/blog/ip-rotation-explained)). این زنجیره اطلاعات ورود را مدیریت می‌کند؛ هویت شما را پنهان نمی‌کند و شرایط ارائه‌دهنده و قاعده‌های هر سایت همچنان برقرارند. ## کلاینت را چگونه وصل و آزمایش کنید؟ این دستورها را از ماشینی در شبکه مجاز اجرا کنید؛ `198.51.100.20` جای سرور شماست. ```bash # 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 با پروکسی](/fa/blog/curl-proxy) و [آزمایش پروکسی](/fa/blog/how-to-test-a-proxy) آمده است. ## سرور پروکسی خودتان به چه کاری می‌آید؟ - **IP خروجی ثابت برای یک API:** فقط ترافیک API از Squid می‌گذرد ([IP ثابت برای API](/fa/blog/static-ip-for-api-access)). - **کنترل دسترسی وب در دفتر:** ACLهای `dstdomain` و `access.log`، به شرط آنکه کارکنان از پیش آگاه شده باشند ([پروکسی و فایروال](/fa/blog/proxy-vs-firewall)). - **تنظیمات مرورگر در دفتر:** یک فایل PAC به هر مرورگر می‌گوید چه زمانی از Squid استفاده کند ([فایل PAC](/fa/blog/pac-file)). - **کش بسته برای ماشین‌های CI:** apt هر بسته HTTP ساده را فقط یک بار دریافت می‌کند ([تنظیمات پروکسی در Linux](/fa/blog/linux-proxy-settings)). - **نه برای کار داده در چند کشور:** بررسی قیمت و اسکرپینگ بر اساس موقعیت به آدرس‌های زیاد نیاز دارد ([استخراج داده](/fa/data-scraping)). ## اشتباه‌های رایج - **`http_access allow all`.** پروکسی باز می‌سازد و IP آن به‌زودی در لیست‌های سیاه قرار می‌گیرد ([لیست سیاه IP](/fa/blog/ip-blacklist)). - **`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 در وب اسکرپینگ](/fa/blog/http-status-codes-web-scraping)). ## راهنمای انتخاب | نیاز | پیشنهاد | |---|---| | تیم باید از یک IP به یک API برسد | Squid روی VPS با IP ثابت همراه با لیست سفید و ورود با رمز، یا یک [پروکسی استاتیک](https://proxynet.io/fa/static-proxy) | | ماشین‌های 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](/fa/blog/port-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 مرکز داده در یک مکان. وقتی کاری به آدرس‌های بیشتر یا کشورهای دیگر نیاز دارد، یک [پروکسی دیتاسنتر](https://proxynet.io/fa/datacenter-proxy) یا یک [پروکسی مسکونی](https://proxynet.io/fa/residential-proxy) این کمبود را پر می‌کند و صفحه [خدمات پروکسی ما](/fa/proxy) گزینه‌ها را با هم مقایسه می‌کند.