راه‌اندازی پروکسی Squid روی اوبونتو: راهنمای کامل

مقدمه

سرورهای پروکسی نوعی اپلیکیشن سرور هستند که به‌عنوان دروازه‌ای میان کاربر نهایی و یک منبع اینترنتی عمل می‌کنند. از طریق یک سرور پروکسی، کاربر نهایی می‌تواند ترافیک وب خود را برای اهداف متنوعی — از جمله حریم خصوصی، امنیت و کش — کنترل و مانیتور کند. مثلاً، می‌توانید از یک سرور پروکسی برای ارسال درخواست‌های وب از یک IP متفاوت با IP خودتان استفاده کنید. همچنین می‌توانید از پروکسی برای تحقیق درباره نحوه سرو شدن متفاوت وب در حوزه‌های قضایی مختلف استفاده کنید یا از برخی روش‌های نظارت یا Throttle شدن ترافیک وب اجتناب کنید.

Squid یک پروکسی HTTP متن‌باز، پایدار و محبوب است. در این آموزش، Squid را نصب و پیکربندی می‌کنید تا یک پروکسی HTTP روی یک سرور اوبونتو 24.04 LTS فراهم کند. این راهنما نسخه‌های فعلی پکیج‌ها، مسیرهای پیکربندی و بهترین شیوه‌ها برای محیط‌های مدرن اوبونتو را منعکس می‌کند.

همچنین دسترسی به پروکسی خود را با قوانین کنترل دسترسی Squid و احراز هویت پایه امن می‌کنید، دسترسی در سطح شبکه را با فایروال محدود می‌کنید و اتصال‌پذیری پروکسی را از یک کلاینت تست می‌کنید. در نهایت، بررسی می‌کنید که چه زمانی ممکن است بخواهید به‌جای آن از یک پروکسی SOCKS5 استفاده کنید (مثلاً Dante)، Squid با سایر راه‌حل‌های رایج پروکسی چطور مقایسه می‌شود و چند سوال متداول درباره بهره‌برداری و عیب‌یابی Squid را مرور می‌کنید.

اپلیکیشن‌های فرانت‌اند خود را با پارمین کلود مستقیماً از گیت‌هاب مستقر کنید و مقیاس‌دهی اپلیکیشن را به پارمین کلود بسپارید.

نکات کلیدی

• Squid یک پروکسی Forward است که برای ترافیک HTTP/HTTPS ساخته شده و برای کنترل دسترسی وب، مانیتورینگ و (به‌صورت اختیاری) کش در محیط‌های تیمی یا شبکه‌ای، انتخابی قوی محسوب می‌شود.
• استقرارهای امن Squid به کنترل دسترسی لایه‌لایه وابسته‌اند: از ACLها/احراز هویت Squid در پیکربندی استفاده کرده و دسترسی ورودی را در فایروال محدود کنید تا یک پروکسی باز (Open Proxy) نسازید.
• قوانین دسترسی Squid به ترتیب وابسته‌اند؛ پس خطوط http_access باید با دقت چیده شوند (قوانین allow/deny خاص اول و «deny all» در آخر) تا از باز شدن تصادفی دسترسی جلوگیری شود.
• قبل از ری‌استارت Squid، ارزشش را دارد که سینتکس پیکربندی خود را اعتبارسنجی کنید تا اشتباهات را زود بگیرید و از Downtime ناشی از شکست ری‌استارت سرویس اجتناب کنید.
• تست با یک ابزار کلاینت مثل curl، راهی کارآمد برای تأیید کارکرد پروکسی شماست (شامل رفتار احراز هویت و HTTPS CONNECT)؛ قبل از شروع پیکربندی مرورگرها یا اپ‌ها.
• Squid یک پروکسی SOCKS نیست؛ اگر نیاز به پروکسی‌کردن پروتکل‌های غیر HTTP یا اپلیکیشن‌هایی دارید که SOCKS می‌خواهند، یک پروکسی SOCKS5 مثل Dante مکمل یا جایگزین بهتری است.
• ابزارهای «پروکسی» قابل‌جانشینی نیستند: پروکسی‌های معکوس (مثل Nginx/HAProxy) برای مدیریت ترافیک ورودی به سرویس‌های Backend هستند، درحالی‌که Squid برای کنترل ترافیک خروجیِ کلاینت است.
• دید عملیاتی از لاگ‌ها و بررسی‌های پایه سرویس می‌آید؛ پس دانستن اینکه Squid لاگ‌ها را کجا می‌نویسد و چطور وضعیت سرویس/پورت را تأیید کنید، کلید عیب‌یابی مداوم است.

پیش‌نیازها

برای تکمیل این راهنما به موارد زیر نیاز دارید:

• یک سرور اوبونتو 24.04 LTS و یک کاربر غیر root با دسترسی sudo. می‌توانید درباره راه‌اندازی کاربری با این دسترسی‌ها در راهنمای «راه‌اندازی اولیه سرور با اوبونتو» بیشتر یاد بگیرید.
• در این آموزش از نام دامنه your_domain استفاده می‌شود؛ اما باید آن را با نام دامنه یا آدرس IP خودتان جایگزین کنید.

مرحله ۱ — نصب پروکسی Squid

Squid کاربردهای زیادی فراتر از مسیریابی ترافیک خروجی یک کاربر منفرد دارد. در زمینه استقرارهای سرور در مقیاس بزرگ، می‌توان از آن به‌عنوان مکانیزم کش توزیع‌شده، یک لود بالانسر یا جزء دیگری از پشته مسیریابی استفاده کرد. با این حال، برخی روش‌های مقیاس‌دهی افقیِ ترافیک سرور که معمولاً شامل سرور پروکسی می‌شدند، در محبوبیت توسط فریم‌ورک‌های کانتینری مانند Kubernetes پشت سر گذاشته شده‌اند؛ که اجزای بیشتری از یک اپلیکیشن را توزیع می‌کنند. هم‌زمان، استفاده از سرورهای پروکسی برای بازگردانی درخواست‌های وب به‌عنوان یک کاربر منفرد، برای حفاظت از حریم خصوصی، محبوب‌تر هم شده است. نگه‌داشتن این موضوع در ذبین هنگام کار با سرورهای پروکسی متن‌باز مفید است؛ چرا که ممکن است ظاهر شوند با ده‌ها قابلیت در حالت نگهداری با اولویت پایین‌تر. کاربردهای یک پروکسی با گذر زمان تغییر کرده اما فناوری پایه نه.

با اجرای دستورات زیر به‌عنوان کاربر غیر root شروع کنید تا فهرست پکیج‌های خود را به‌روز کرده و پروکسی Squid را نصب کنید:

sudo apt update
sudo apt install squid

Squid به‌طور خودکار یک سرویس پس‌زمینه راه‌اندازی کرده و بعد از نصب شروع به کار می‌کند. می‌توانید بررسی کنید که سرویس به‌درستی در حال اجراست:

systemctl status squid

خروجی:

● squid.service - Squid Web Proxy Server
     Loaded: loaded (/usr/lib/systemd/system/squid.service; enabled; preset: enabled)
     Active: active (running) since Fri 2026-04-24 02:07:21 EDT; 19s ago
       Docs: man:squid(8)
    Process: 3133998 ExecStartPre=/usr/sbin/squid --foreground -z (code=exited, status=0/SUCCESS)
   Main PID: 3134009 (squid)
      Tasks: 4 (limit: 4653)
     Memory: 17.7M (peak: 18.5M)
        CPU: 244ms
     CGroup: /system.slice/squid.service
             ├─3134009 /usr/sbin/squid --foreground -sYC
             ├─3134016 "(squid-1)" --kid squid-1 --foreground -sYC
             ├─3134017 "(logfile-daemon)" /var/log/squid/access.log
             └─3134019 "(pinger)"

به‌صورت پیش‌فرض، Squid به هیچ کلاینتی اجازه اتصال از خارج این سرور را نمی‌دهد. برای فعال‌کردن آن، باید تغییراتی در فایل پیکربندی‌اش — که در /etc/squid/squid.conf ذخیره شده — ایجاد کنید. آن را با nano یا ویرایشگر متن دلخواه خود باز کنید:

sudo nano /etc/squid/squid.conf

توجه داشته باشید که فایل پیکربندی پیش‌فرض Squid خیلی خیلی طولانی است و شامل تعداد عظیمی از گزینه‌هاست که به‌صورت موقت با قرار دادن # در ابتدای خط‌شان غیرفعال شده‌اند؛ که به آن کامنت‌شدن (Commented Out) هم گفته می‌شود. به‌احتمال زیاد می‌خواهید در فایل جست‌وجو کنید تا خطوط موردنظرتان برای ویرایش را پیدا کنید. در nano این کار با فشردن Ctrl+W، وارد کردن عبارت جست‌وجو، فشردن Enter و سپس فشردن مکرر Alt+W برای یافتن نمونه بعدی آن عبارت در صورت نیاز انجام می‌شود.

با مراجعه به خطی که عبارت http_access deny all را در بر دارد شروع کنید. باید بلوکی از متن را ببینید که قوانین دسترسی پیش‌فرض Squid را توضیح می‌دهد:

/etc/squid/squid.conf

. . . 
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
include /etc/squid/conf.d/*

# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
#http_access allow localnet
http_access allow localhost

# And finally deny all other access to this proxy
http_access deny all
. . .

از این می‌توانید رفتار فعلی را ببینید — localhost مجاز است؛ سایر اتصالات نه. توجه کنید که این قوانین به‌صورت ترتیبی تجزیه (Parse) می‌شوند؛ پس ایده خوبی است که قانون deny all را در انتهای این بلوک پیکربندی نگه دارید. می‌توانستید آن قانون را به allow all تغییر دهید تا هر کسی بتواند به سرور پروکسی شما متصل شود؛ اما احتمالاً نمی‌خواهید این کار را بکنید. به‌جای آن، می‌توانید خطی بالای http_access allow localhost اضافه کنید که IP خودتان را در بر بگیرد؛ به این شکل:

/etc/squid/squid.conf

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
include /etc/squid/conf.d/*

# Example rule allowing access from your local networks.
acl localnet src your_ip_address

# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow localnet
http_access allow localhost

• مقدار acl یعنی یک Access Control List (فهرست کنترل دسترسی)؛ اصطلاحی رایج برای سیاست‌های دسترسی.
• مقدار localnet در این مورد، نام ACL شماست.
• مقدار src جایی است که درخواست تحت این ACL از آن سرچشمه می‌گیرد؛ یعنی آدرس IP شما.

توجه کنید که باید خط http_access allow localnet را هم اضافه کرده یا از کامنت خارج کنید تا ACLای که همین الان تعریف کردید عملاً مجاز شود.

اگر IP محلی خود را نمی‌دانید، سریع‌ترین راه مراجعه به سایتی مثل What’s my IP است که می‌تواند به شما بگوید از کجا به آن دسترسی داشته‌اید. پس از اعمال این تغییرات، فایل را ذخیره کرده و ببندید. اگر از nano استفاده می‌کنید، Ctrl+X را فشار داده و سپس هنگام درخواست، Y و بعد Enter را بزنید.

در این نقطه می‌توانستید Squid را ری‌استارت کرده و به آن متصل شوید؛ اما کارهای بیشتری هست که ابتدا می‌توانید برای امن‌کردن آن انجام دهید.

مرحله ۲ — امن‌سازی Squid

بیشتر پروکسی‌ها و بیشتر اپ‌های سمت کلاینت که به پروکسی‌ها متصل می‌شوند (مثلاً مرورگرهای وب) از چندین روش احراز هویت پشتیبانی می‌کنند. این روش‌ها می‌توانند شامل کلیدهای مشترک یا سرورهای احراز هویت جداگانه باشند؛ اما معمولاً شامل جفت‌های نام کاربری/رمز عبور معمولی هستند. Squid به شما اجازه می‌دهد با استفاده از قابلیت‌های داخلی لینوکس، جفت‌های نام کاربری/رمز عبور بسازید؛ به‌عنوان گامی اضافی یا جایگزین برای محدودکردن دسترسی به پروکسی با آدرس IP. برای این کار، فایلی به نام /etc/squid/passwords می‌سازید و پیکربندی Squid را به آن اشاره می‌دهید.

ابتدا، باید چند ابزار از پروژه Apache نصب کنید تا به یک تولیدکننده رمز عبور که Squid با آن راحت است، دسترسی داشته باشید.

sudo apt install apache2-utils

این پکیج دستور htpasswd را فراهم می‌کند که می‌توانید از آن برای تولید رمز عبور برای کاربر جدید Squid استفاده کنید. نام‌های کاربری Squid به هیچ وجه با نام‌های کاربری سیستم هم‌پوشانی ندارند؛ پس اگر بخواهید می‌توانید از همان نامی که با آن وارد شده‌اید استفاده کنید. برای افزودن رمز عبور هم از شما خواسته می‌شود:

sudo htpasswd -c /etc/squid/passwords your_squid_username

این کار نام کاربری شما را به‌همراه هشِ رمز عبور جدیدتان در /etc/squid/passwords ذخیره می‌کند؛ که به‌عنوان منبع احراز هویت توسط Squid استفاده خواهد شد. می‌توانید بعداً فایل را cat کنید تا ببینید چه شکلی است:

sudo cat /etc/squid/passwords

خروجی:

sammy:$apr1$Dgl.Mtnd$vdqLYjBGdtoWA47w4q1Td.

پس از تأیید اینکه نام کاربری و رمز عبورتان ذخیره شده‌اند، می‌توانید پیکربندی Squid را به‌روزرسانی کنید تا از فایل جدید /etc/squid/passwords شما استفاده کند. با nano یا ویرایشگر متن دلخواه خود، فایل پیکربندی Squid را دوباره باز کرده و خطوط هایلایت‌شده زیر را اضافه کنید:

sudo nano /etc/squid/squid.conf

/etc/squid/squid.conf

…
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
include /etc/squid/conf.d/*
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwords
auth_param basic realm proxy
acl authenticated proxy_auth REQUIRED
# Example rule allowing access from your local networks.
acl localnet src your_ip_address
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow localhost
http_access allow authenticated localnet
# And finally deny all other access to this proxy
http_access deny all
…

توجه: روی اوبونتو 24.04، هلپرهای احراز هویت زیر /usr/lib/squid/ قرار دارند. آموزش‌های قدیمی‌تر ممکن است به /usr/lib/squid3/ اشاره کنند که روی سیستم‌های جدیدتر کار نمی‌کند.

این Directiveهای اضافی به Squid می‌گویند که در فایل رمزهای عبور جدید شما به‌دنبال هش‌هایی بگردد که با مکانیزم basic_ncsa_auth قابل تجزیه هستند و دسترسی به پروکسی شما را مشروط به احراز هویت کنند. برای اطلاعات بیشتر درباره این روش یا سایر روش‌های احراز هویت، می‌توانید مستندات Squid را بررسی کنید. پس از آن، می‌توانید در نهایت Squid را با تغییرات پیکربندی خود ری‌استارت کنید.

چون قانون http_access allow authenticated localnet هر دو ACL را در بر می‌گیرد، کلاینت‌ها باید از محدوده IPای که تعریف کردید متصل شوند و اطلاعات احراز هویت معتبر هم ارائه دهند.

اگر در مرحله ۱ خط http_access allow localnet را اضافه کرده‌اید، مطمئن شوید قبل از ری‌استارت Squid آن را کامنت کنید یا حذف کنید. در غیر این صورت، Squid به هر کلاینتی که با ACL مربوط به localnet مطابقت داشته باشد، دسترسی بدون احراز هویت می‌دهد.

اما قبل از ری‌استارت سرویس Squid، ایده خوبی است که پیکربندی خود را از نظر خطاهای سینتکس بررسی کنید. این کار کمک می‌کند از شکست سرویس به دلیل Directiveهای نامعتبر جلوگیری شود.

دستور زیر را اجرا کنید:

sudo squid -k parse

اگر مشکلی در فایل پیکربندی شما وجود داشته باشد، Squid آن‌ها را در خروجی نمایش می‌دهد. اگر خطایی گزارش نشد، می‌توانید با خیال راحت به ری‌استارت سرویس ادامه دهید.

sudo systemctl restart squid

این کار ممکن است کمی طول بکشد.

علاوه بر پیکربندی کنترل دسترسی داخل Squid، مهم است که دسترسی در سطح شبکه به پروکسی خود را با فایروال محدود کنید. روی اوبونتو این کار معمولاً با UFW (‏Uncomplicated Firewall) انجام می‌شود.

به‌صورت پیش‌فرض، اگر بدون محدودیت اجازه ترافیک روی پورت 3128 را بدهید، ممکن است سرور شما به یک پروکسی باز تبدیل شود؛ که می‌تواند توسط کاربران غیرمجاز سوءاستفاده شده و به سیاه‌شدن (Blacklist) آدرس IP شما منجر شود.

به‌جای اجازه‌دادنِ دسترسی نامحدود:

sudo ufw allow 3128

باید دسترسی را فقط به آدرس‌های IP کلاینت‌های مورد اعتماد محدود کنید:

sudo ufw allow from your_client_ip to any port 3128

مثلاً:

sudo ufw allow from 203.0.113.10 to any port 3128

پس از افزودن قانون، برای اعمال تغییرات، UFW را Reload کنید:

sudo ufw reload

می‌توانید قوانین فعال فایروال را با این دستور تأیید کنید:

sudo ufw status

استفاده از UFW در کنار پیکربندی ACL مربوط به Squid، با اعمال کنترل دسترسی هم در سطح شبکه و هم در سطح اپلیکیشن، لایه امنیتی اضافی‌ای فراهم می‌کند.

در مرحله بعد، در نهایت به پروکسی خود متصل می‌شوید.

مرحله ۳ — اتصال از طریق Squid

برای نمایش سرور Squid خود، از برنامه خط فرمانی به نام curl استفاده می‌کنید که برای ارسال انواع مختلف درخواست‌های وب محبوب است. به‌طور کلی، اگر می‌خواهید تأیید کنید که یک اتصالِ مشخص باید در شرایط ایده‌آل در یک مرورگر کار کند، همیشه باید اول با curl تست کنید. برای این کار از curl روی ماشین محلی خود استفاده می‌کنید — این ابزار به‌صورت پیش‌فرض روی همه محیط‌های مدرن ویندوز، مک و لینوکس نصب است؛ پس می‌توانید هر شل محلی را باز کرده و این دستور را اجرا کنید:

curl -v -x http://your_squid_username:your_squid_password@your_server_ip:3128 http://www.google.com/

آرگومان x- یک سرور پروکسی را به curl پاس می‌دهد و در این مورد از پروتکل http:// استفاده می‌کنید؛ نام کاربری و رمز عبور خود را برای این سرور مشخص کرده و سپس به یک وب‌سایت شناخته‌شده و کارآمد مثل google.com متصل می‌شوید. اگر دستور موفق بود، باید خروجی زیر را ببینید:

خروجی:

*   Trying 138.197.103.77...
* TCP_NODELAY set
* Connected to 138.197.103.77 (138.197.103.77) port 3128 (#0)
* Proxy auth using Basic with user 'sammy'
> GET http://www.google.com/ HTTP/1.1

همچنین بدون هیچ تغییر پیکربندی اضافه‌ای، می‌توان با پروکسی Squid خود به وب‌سایت‌های https:// دسترسی پیدا کرد. این‌ها از یک Directive جداگانه پروکسی به نام CONNECT استفاده می‌کنند تا SSL بین کلاینت و سرور حفظ شود:

curl -v -x http://your_squid_username:your_squid_password@your_server_ip:3128 https://www.google.com/

خروجی:

*   Trying 138.197.103.77...
* TCP_NODELAY set
* Connected to 138.197.103.77 (138.197.103.77) port 3128 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to www.google.com:443
* Proxy auth using Basic with user 'sammy'
> CONNECT www.google.com:443 HTTP/1.1
> Host: www.google.com:443
> Proxy-Authorization: Basic c2FtbXk6c2FtbXk=
> User-Agent: curl/7.55.1
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
<
* Proxy replied OK to CONNECT request
* CONNECT phase completed!

اطلاعات احراز هویتی که برای curl استفاده کردید، اکنون باید در هر جای دیگری که بخواهید از سرور پروکسی جدید خود استفاده کنید کار کند.

راه‌اندازی پروکسی SOCKS5 روی اوبونتو (جایگزین Squid)

درحالی‌که Squid به‌طور خاص برای پروکسی‌کردن HTTP و HTTPS طراحی شده، برخی اپلیکیشن‌ها به یک پروتکل پروکسی منعطف‌تر مانند SOCKS5 نیاز دارند. برخلاف پروکسی‌های HTTP، SOCKS5 در سطح پایین‌تری از پشته شبکه کار می‌کند و می‌تواند طیف وسیع‌تری از ترافیک — شامل اتصالات TCP و UDP — را هندل کند. این موضوع آن را برای مواردی مانند تونل‌کردن SSH، کلاینت‌های تورنت و اپلیکیشن‌هایی که به‌صورت بومی از پروکسی‌های HTTP پشتیبانی نمی‌کنند مناسب می‌سازد.

Squid پشتیبانی بومی از SOCKS5 ندارد. برای استقرار یک پروکسی SOCKS5 روی اوبونتو، می‌توانید از یک سرور پروکسی اختصاصی مانند Dante استفاده کنید؛ که سبک، فعالانه نگهداری‌شده و برای پروکسی SOCKS به‌طور گسترده استفاده می‌شود.

نصب پروکسی SOCKS دانته

ایندکس پکیج‌های خود را به‌روز کرده و پکیج سرور Dante را نصب کنید:

sudo apt update
sudo apt install dante-server

این کار دیمن Dante ‏(‏danted) را نصب می‌کند؛ که هسته سرویس پروکسی SOCKS5 است؛ به‌همراه یک فایل پیکربندی پیش‌فرض در /etc/danted.conf. مثل Squid، می‌توانید آن را با دستورات استاندارد systemd مدیریت کنید.

پیکربندی پایه

رفتار Dante از طریق فایل /etc/danted.conf کنترل می‌شود؛ مشابه نحوه استفاده Squid از /etc/squid/squid.conf. آن را در ویرایشگر متن دلخواه خود باز کنید:

sudo nano /etc/danted.conf

محتوای پیش‌فرض را با پیکربندی مینیمال زیر جایگزین کنید:

/etc/danted.conf

logoutput: syslog

internal: 0.0.0.0 port = 1080
external: eth0

method: username none

user.notprivileged: nobody

client pass {
    from: 0.0.0.0/0 to: 0.0.0.0/0
}

pass {
    from: 0.0.0.0/0 to: 0.0.0.0/0
    protocol: tcp udp
}

در این پیکربندی:

• internal: آدرس IP و پورتی را مشخص می‌کند که Dante برای اتصالات ورودی روی آن گوش می‌دهد. مقدار 0.0.0.0 به Dante می‌گوید اتصالات از هر اینترفیس شبکه‌ای را روی پورت 1080 — که پورت استاندارد SOCKS5 است — بپذیرد.
• external: اینترفیس شبکه‌ای را تعریف می‌کند که Dante برای ترافیک خروجی استفاده می‌کند. باید eth0 را با نام واقعی اینترفیس خود — مانند ens3 یا enp0s3 — جایگزین کنید. می‌توانید اینترفیس خود را با اجرای ip a و پیدا کردن آنکه IP فعال دارد پیدا کنید.
• method: روش‌های احراز هویتی را تعریف می‌کند که Dante می‌پذیرد. مقدار username none هم اتصالات احراز هویت‌شده (با نام کاربری/رمز عبور) و هم اتصالات بدون احراز هویت را مجاز می‌کند. برای production باید none را حذف کنید تا احراز هویت الزامی شود.
• client pass و pass: این بلوک‌ها قوانین کنترل دسترسی را برای اینکه چه کسی می‌تواند به پروکسی شما متصل شود و چه ترافیکی را می‌تواند از طریق آن ارسال کند، تعریف می‌کنند. در این پیکربندی، هر دو بلوک به همه کلاینت‌ها (‏0.0.0.0/0) اجازه اتصال و پروکسی‌کردن ترافیک به هر جا را می‌دهند. این برای تست مناسب است اما در production باید به محدوده‌های IP خاصی محدود شود.

توجه: برای امنیت، فیلد from را به محدوده‌های IP خاص محدود کنید؛ به‌جای اجازه‌دادن 0.0.0.0/0.

راه‌اندازی و فعال‌سازی سرویس

پس از ذخیره فایل پیکربندی، سرویس Dante را ری‌استارت کنید:

sudo systemctl restart danted

آن را برای راه‌اندازی خودکار هنگام بوت فعال کنید:

sudo systemctl enable danted

برای تأیید اینکه سرویس به‌درستی در حال اجراست، وضعیتش را بررسی کنید:

systemctl status danted

اگر سرویس به‌درستی اجرا می‌شود، خروجی‌ای می‌بینید که نشان می‌دهد active (running) است و بدون پیام خطا.

مجاز کردن ترافیک SOCKS5 از طریق فایروال

اگر از UFW (‏Uncomplicated Firewall) استفاده می‌کنید، باید ترافیک به پورت SOCKS5 را مجاز کنید تا کلاینت‌ها بتوانند به پروکسی شما متصل شوند.

به‌جای اجازه‌دادن دسترسی نامحدود از هر آدرس IP با این دستور:

sudo ufw allow 1080

باید از قانون محدودکننده‌تری استفاده کنید که فقط کلاینت‌های مورد اعتماد را مجاز بداند:

sudo ufw allow from your_client_ip to any port 1080

مثلاً:

sudo ufw allow from 203.0.113.10 to any port 1080

برای اعمال تغییرات، فایروال را Reload کنید:

sudo ufw reload

این موضوع برای جلوگیری از تبدیل‌شدن سرور شما به یک پروکسی باز مهم است؛ که می‌تواند سوءاستفاده شود و باعث سیاه‌شدن سرور شما در فهرست‌ها شود.

تست پروکسی SOCKS5

می‌توانید با استفاده از curl از ماشین محلی خود تأیید کنید که پروکسی SOCKS5 شما به‌درستی کار می‌کند:

curl -x socks5h://your_server_ip:1080 http://example.com

طرح socks5h به curl می‌گوید تفکیک DNS را از طریق سرور پروکسی انجام دهد؛ نه به‌صورت محلی روی ماشین شما. این کار حریم خصوصی اضافی فراهم می‌کند؛ چون از لو رفتن سایت‌هایی که به آن‌ها دسترسی دارید توسط کوئری‌های DNS محلی جلوگیری می‌شود. اگر درخواست موفق باشد و محتوای HTML برگرداند، پروکسی شما به‌درستی کار می‌کند.

چه زمانی به‌جای Squid از SOCKS5 استفاده کنیم

SOCKS5 انتخاب بهتری است وقتی به انعطاف بیشتری از آنچه پروکسی‌کردن مخصوص HTTP فراهم می‌کند نیاز دارید. SOCKS5 را در صورتی در نظر بگیرید که نیاز دارید پروتکل‌های غیر HTTP مانند SSH، FTP یا ترافیک اپلیکیشنی سفارشی‌ای که با پروکسی‌های HTTP کار نمی‌کند را پروکسی کنید. همچنین وقتی ابزارهایتان صریحاً پشتیبانی پروکسی SOCKS لازم دارند یا وقتی یک پروکسی مستقل از پروتکل می‌خواهید که در لایه انتقال کار کند — بدون بازرسی یا تغییر ترافیکِ در حال عبور از آن.

از طرف دیگر، Squid به‌طور خاص برای ترافیک HTTP و HTTPS مناسب‌تر است. Squid در کش محتوا و بهینه‌سازی پهنای باند عالی است؛ که می‌تواند کارایی محتوای وبِ پر دسترسی را به‌طور چشمگیر بهبود بدهد. همچنین با استفاده از ACLها، کنترل دسترسی دقیقی فراهم می‌کند و برای کنترل اینکه کدام کاربران می‌توانند به کدام وب‌سایت‌ها دسترسی داشته باشند و اعمال سیاست‌های فیلتر محتوا، ایده‌آل است.

در بسیاری از محیط‌های production می‌توانید Squid و یک پروکسی SOCKS5 را با هم روی همان سرور یا شبکه مستقر کنید. این به شما اجازه می‌دهد انواع مختلف ترافیک و کاربرد را پشتیبانی کنید — ترافیک HTTP/HTTPS برای بهره‌مندی از کش از طریق Squid مسیریابی می‌شود، درحالی‌که ترافیک غیر HTTP برای پشتیبانی پروتکلی گسترده‌تر از SOCKS5 می‌گذرد.

انتخاب پروکسی مناسب

Squid همچنان یک پروکسی Forward پرکاربرد است؛ به‌خصوص در استقرارهای سازمانی و در سطح شبکه‌ای که کنترل، کش و فیلتر ترافیک لازم است. با این حال، تنها گزینه موجود نیست. بسته به مورد استفاده شما، ابزارهای پروکسی دیگری ممکن است مناسب‌تر باشند.

درک مقایسه Squid با راه‌حل‌های جایگزین به شما کمک می‌کند تعیین کنید که آیا برای محیط شما انتخاب درستی است یا نه.

مقایسه Squid با سایر راه‌حل‌های پروکسی

ابزار	نوع پروکسی	ترافیک پشتیبانی‌شده	قابلیت‌های کلیدی	بهترین مورد استفاده
Squid	پروکسی Forward	HTTP، HTTPS	کش، ACLها، کنترل دسترسی، لاگ‌گیری	پروکسی سازمانی، بهینه‌سازی پهنای باند
Dante	پروکسی SOCKS5	TCP، UDP (مستقل از پروتکل)	هندل انعطاف‌پذیر ترافیک، پروکسی سطح پایین	ترافیک غیر HTTP، پروکسی در سطح اپلیکیشن
Nginx	پروکسی معکوس	HTTP، HTTPS	لود بالانسینگ، خاتمه SSL، مسیریابی	سرو کردن اپلیکیشن‌های Backend
HAProxy	پروکسی معکوس	TCP، HTTP	لود بالانسینگ با کارایی بالا، Failover	توزیع ترافیک در مقیاس بزرگ
Tinyproxy	پروکسی سبک	HTTP، HTTPS	پیکربندی مینیمال، مصرف منابع پایین	راه‌اندازی‌های ساده یا محدود از نظر منابع

چند نکته کلیدی که هنگام مقایسه این گزینه‌های پروکسی باید در ذین داشته باشید:

• Squid برای ترافیک وب بهینه شده است: Squid در پروکسی‌کردن HTTP و HTTPS با کش داخلی محتوا که می‌تواند هزینه‌های پهنای باند را به‌طور چشمگیر کاهش دهد، عالی است. سیستم Access Control List (ACL) آن به شما اجازه می‌دهد قوانین دقیقی درباره اینکه چه کسی به چه چیزی دسترسی دارد بسازید؛ که آن را به‌خصوص در محیط‌های سازمانی که نیاز به اعمال سیاست‌های مرور و مانیتور مصرف پهنای باند دارید، ارزشمند می‌کند.
• پروکسی‌های SOCKS5 (مثل Dante) پشتیبانی پروتکلی گسترده‌تری ارائه می‌دهند: برخلاف پروکسی‌های مخصوص HTTP، SOCKS5 در لایه انتقال کار کرده و بدون درک پروتکل اپلیکیشن، می‌تواند تقریباً هر ترافیک TCP یا UDPای را پروکسی کند. این آن را برای تونل‌کردن اتصالات SSH، مسیریابی کوئری‌های پایگاه داده یا هندل پروتکل‌های سفارشی‌ای که با پروکسی‌های HTTP کار نمی‌کنند، عالی می‌سازد. با این حال، نمی‌تواند مثل Squid کش یا فیلتر محتوا فراهم کند.
• پروکسی‌های معکوس (‏Nginx، HAProxy) نقش متفاوتی دارند: درحالی‌که پروکسی‌های Forward مثل Squid به کلاینت‌ها در دسترسی به منابع خارجی کمک می‌کنند، پروکسی‌های معکوس در جهت مخالف کار می‌کنند — جلوی سرورهای Backend شما قرار گرفته و درخواست‌های ورودی را مدیریت می‌کنند. آن‌ها برای لود بالانسینگ، خاتمه SSL و مسیریابی ترافیک بر اساس الگوهای URL طراحی شده‌اند. اگر در حال ساخت یک اپلیکیشن وب یا API هستید، به یک پروکسی معکوس نیاز دارید، نه یک پروکسی Forward.
• پروکسی‌های سبک، سادگی را بر قابلیت‌ها ترجیح می‌دهند: ابزارهایی مانند Tinyproxy برای سناریوهایی طراحی شده‌اند که در آن‌ها به پروکسی‌کردن پایه HTTP/HTTPS — بدون پیچیدگی پیکربندی Squid — نیاز دارید. راه‌اندازی‌شان سریع‌تر بوده و منابع کمتری مصرف می‌کنند؛ اما معمولاً کش، لاگ‌گیری دقیق یا قابلیت‌های پیشرفته ACLای که Squid را برای استقرارهای بزرگ‌تر مناسب می‌کند را ارائه نمی‌دهند.

چه زمانی باید از Squid استفاده کنید؟

Squid انتخابی قوی است اگر به این موارد نیاز داشته باشید:

• کنترل متمرکز روی ترافیک خروجی وب: اعمال سیاست‌های مرورِ سازگار روی چندین کاربر همراه با لاگ‌گیری و مانیتورینگ همه درخواست‌های وب.
• کش محتوا برای کاهش مصرف پهنای باند: سرو کردن نسخه‌های کش‌شده محتوای پرِ دسترسی مانند دانلودهای نرم‌افزاری، به‌روزرسانی‌های سیستم یا وب‌سایت‌های محبوب؛ به‌جای دریافت مکرر آن‌ها.
• سیاست‌های دسترسی دقیق با استفاده از ACLها: کنترل ریزدانه بر اینکه کدام کاربران می‌توانند به دامنه‌ها یا الگوهای URL خاص دسترسی داشته باشند؛ با پشتیبانی از قوانین زمان‌محور (Time-Based) و احراز هویت.
• یک راه‌حل پروکسی مقیاس‌پذیر: هندل کارآمد صدها یا هزاران اتصال همراه با لاگ‌گیری و مانیتورینگ جامع برای تیم‌ها یا شبکه‌های بزرگ‌تر.

چه زمانی باید جایگزین‌ها را در نظر بگیرید؟

ممکن است بخواهید ابزارهای دیگر را در نظر بگیرید اگر:

• نیاز به پروکسی‌کردن ترافیک غیر HTTP دارید: Squid به‌طور خاص برای HTTP و HTTPS طراحی شده. برای پروتکل‌هایی مثل SSH، FTP، SMTP یا اتصالات پایگاه داده، به یک پروکسی SOCKS5 مثل Dante نیاز دارید که در لایه انتقال کار می‌کند.
• در حال مسیریابی ترافیک به سرویس‌های Backend هستید: پروکسی‌های Forward به کلاینت‌ها در دسترسی به منابع خارجی کمک می‌کنند. برای توزیع درخواست‌های ورودی وب روی چندین سرور Backend یا هندل خاتمه SSL، به‌جای آن از یک پروکسی معکوس مثل Nginx یا HAProxy استفاده کنید.
• یک راه‌اندازی ساده و سبک می‌خواهید: اگر فقط برای استفاده شخصی یا تعداد کمی کاربر، بدون کش یا ACLهای دقیق، به پروکسی‌کردن پایه HTTP/HTTPS نیاز دارید، یک پروکسی مینیمال مثل Tinyproxy راحت‌تر پیکربندی و نگهداری می‌شود.

Squid همچنان ابزاری مرتبط و قدرتمند برای مدیریت ترافیک وب در محیط‌های مدرن است. اگرچه راه‌حل‌های پروکسی جایگزین وجود دارند، اما معمولاً موارد استفاده متفاوتی را هدف می‌گیرند تا اینکه کاملاً جایگزین Squid شوند. انتخاب ابزار مناسب به نوع ترافیکی که باید هندل کنید و سطح کنترل موردنیاز بستگی دارد.

سوالات متداول

۱. چطور پروکسی Squid را در اوبونتو پیکربندی کنم؟

پس از نصب Squid (مثلاً sudo apt install squid)، فایل /etc/squid/squid.conf را ویرایش کنید تا ACLها را تعریف کنید، پورت گوش‌دادن را با http_port تنظیم کنید و دسترسی را با قوانین http_access کنترل کنید. پیکربندی خود را با sudo squid -k parse بررسی کرده و سپس تغییرات را با sudo systemctl restart squid اعمال کنید.

۲. چطور روی اوبونتو یک پروکسی SOCKS5 راه‌اندازی کنم؟

Squid به‌صورت بومی از SOCKS5 پشتیبانی نمی‌کند. برای SOCKS5، از یک سرور SOCKS اختصاصی مثل Dante استفاده کنید (دیمن آن معمولاً danted است) یا از فوروارد پورت داینامیک SSH (مثلاً ssh -D 1080 user@your_server_ip). Squid یک پروکسی Forward مربوط به HTTP/HTTPS است؛ درحالی‌که SOCKS5 یک پروکسی مستقل از پروتکل است.

۳. چطور در اوبونتو به‌صورت سراسری، پروکسی را تنظیم کنم؟

مقادیر http_proxy و https_proxy (و به‌صورت اختیاری no_proxy) را در /etc/environment تنظیم کنید؛ یا تنظیمات پروکسی دسکتاپ را در گنوم زیر مسیر Settings -> Network -> Network Proxy پیکربندی کنید. برای APT، تنظیمات پروکسی را زیر /etc/apt/apt.conf.d/ اضافه کنید (مثلاً /etc/apt/apt.conf.d/proxy.conf).

۴. آیا پروکسی Squid هنوز در سال ۲۰۲۵ استفاده می‌شود؟

بله. Squid فعالانه نگهداری می‌شود و همچنان به‌طور گسترده برای کش، کنترل دسترسی و ممیزی در شبکه‌های سازمانی و خطوط لوله اتوماسیون مستقر است. همچنین از بازرسی اختیاری HTTPS (‏SSL Bump) پشتیبانی می‌کند؛ اما آن نیازمند مدیریت دقیق گواهی‌ها و یک سیاست امنیتی شفاف است.

۵. پروکسی Squid به‌صورت پیش‌فرض از چه پورتی استفاده می‌کند؟

Squid به‌صورت پیش‌فرض روی پورت 3128 گوش می‌دهد؛ که توسط http_port 3128 در squid.conf تنظیم شده است. اگر آن را تغییر دادید، مطمئن شوید قوانین فایروال (‏UFW/iptables) شما پورت جدید را مجاز می‌کنند.

۶. چطور بررسی کنم که پروکسی Squid روی اوبونتو در حال اجراست؟

دستور sudo systemctl status squid را برای بررسی وضعیت سرویس اجرا کنید. همچنین می‌توانید با sudo ss -tlnp | grep squid (یا با بررسی وجود پورت 3128) تأیید کنید که در حال گوش دادن است.

۷. چطور با Squid دسترسی به وب‌سایت‌های خاص را محدود کنم؟

یک ACL از نوع dstdomain در squid.conf تعریف کنید (مثلاً acl blocked_sites dstdomain .example.com)؛ سپس آن را با http_access deny blocked_sites رد کنید. قانون deny را بالای قوانین allow خود قرار داده و سپس Squid را ری‌استارت کنید.

۸. چطور لاگ‌گیری را در Squid فعال کنم و فایل‌های لاگ کجا هستند؟

به‌صورت پیش‌فرض، Squid لاگ درخواست‌ها را در /var/log/squid/access.log و لاگ‌های کش/سرویس را در /var/log/squid/cache.log می‌نویسد. می‌توانید ترافیک را با sudo tail -f /var/log/squid/access.log مانیتور کرده یا لاگ‌های سرویس را با journalctl -u squid ببینید.

جمع‌بندی

در این آموزش، Squid را نصب و پیکربندی کردید؛ یک سرور پروکسی متن‌باز و محبوب برای مدیریت ترافیک HTTP و HTTPS. همچنین کنترل‌های دسترسی را پیکربندی کردید، پیکربندی خود را اعتبارسنجی کرده و اتصال‌پذیری پروکسی را از یک کلاینت تست کردید. بسیاری از اپلیکیشن‌ها — اغلب در سطح سیستم‌عامل — ده‌ها سال است که از پشتیبانی داخلی پروکسی برخوردارند؛ که این راه‌اندازی را به‌طور گسترده قابل‌استفاده مجدد می‌کند.

اگر نیاز دارید ترافیک غیر HTTP را پروکسی کنید یا اپلیکیشن‌هایی را پشتیبانی کنید که SOCKS لازم دارند، می‌توانید Squid را با یک پروکسی SOCKS5 تکمیل کنید. در قدم بعدی شاید بخواهید یاد بگیرید که چطور Dante را مستقر کنید؛ یک پروکسی SOCKS که می‌تواند در کنار Squid برای پروکسی‌کردن انواع مختلف ترافیک اجرا شود.

چون یکی از رایج‌ترین کاربردهای سرورهای پروکسی، پروکسی‌کردن ترافیک به/از مناطق مختلف جهانی است، ممکن است در ادامه بخواهید استفاده از Ansible برای خودکارسازی استقرار سرورها را مرور کنید؛ به‌خصوص اگر برنامه‌دارید این پیکربندی را روی چندین سرور یا منطقه تکرار کنید.