در این مقاله با مفهوم ریورس پراکسی آشنا می‌شوید، یاد می‌گیرید چرا هر سرور پروداکشنی به آن نیاز دارد، و قدم‌به‌قدم یک تنظیم واقعی با Nginx پیاده‌سازی می‌کنیم.

یک سوال ساده برای شروع

فرض کنید یک اپلیکیشن Node.js نوشته‌اید که روی پورت 3000 اجرا می‌شود. وقتی می‌خواهید آن را روی سرور منتشر کنید، چند سوال ذهنتان را درگیر می‌کند:

• کاربر که example.com می‌زند، چطور به پورت 3000 می‌رسد؟

• اگر چند سرویس مختلف داشتم، چطور مدیریتشان کنم؟

• SSL چطور تنظیم می‌شود؟

• اگر ترافیک زیاد شد، بار را چطور تقسیم کنم؟

جواب همه این سوال‌ها یک چیز است: ریورس پراکسی.

ریورس پراکسی دقیقاً چیست؟

قبل از اینکه وارد Nginx شویم، باید مفهوم پراکسی را درست بفهمیم.

فرق پراکسی معمولی با ریورس پراکسی

• پراکسی معمولی (Forward Proxy): جلوی کلاینت می‌نشیند. یعنی درخواست‌های کاربر را می‌گیرد و به اینترنت می‌فرستد. سرور مقصد نمی‌داند درخواست از کجا آمده. در شبکه‌های سازمانی یا VPNها از این نوع استفاده می‌شود.

• ریورس پراکسی (Reverse Proxy): جلوی سرور می‌نشیند. یعنی کلاینت فکر می‌کند دارد مستقیم با سرور اصلی صحبت می‌کند، اما در واقع با ریورس پراکسی در ارتباط است. ریورس پراکسی درخواست را می‌گیرد، پردازش می‌کند و به سرور مناسب می‌فرستد.

یک تصویر ذهنی ساده: ریورس پراکسی مثل نگهبان یا منشی جلوی یک ساختمان بزرگ است. هر کسی که می‌آید، او راهنمایی می‌کند به کدام اتاق برود.

چرا ریورس پراکسی اینقدر مهم است؟

در یک محیط پروداکشن واقعی، ریورس پراکسی وظایف زیادی به عهده می‌گیرد:

• SSL Termination: مدیریت گواهینامه HTTPS در یک جا متمرکز می‌شود. سرویس‌های پشتی می‌توانند بدون SSL روی شبکه داخلی کار کنند.

• Load Balancing: ترافیک بین چند نمونه از یک سرویس تقسیم می‌شود تا هیچ کدام اشباع نشوند.

• Caching: پاسخ‌های تکراری ذخیره می‌شوند تا سرور اصلی بار کمتری داشته باشد.

• Static File Serving: فایل‌های CSS، JS و تصاویر مستقیم از ریورس پراکسی سرو می‌شوند بدون اینکه سرور برنامه اصلی درگیر شود.

• Security: آدرس و پورت سرورهای اصلی از کاربر پنهان می‌ماند. می‌توان rate limiting و فیلتر IP را در این لایه اعمال کرد.

• Logging: تمام درخواست‌ها در یک نقطه لاگ می‌شوند.

چرا Nginx؟

Nginx (تلفظ: انجین-ایکس) یک وب‌سرور با کارایی بالاست که به عنوان ریورس پراکسی هم استفاده می‌شود. در سال ۲۰۰۴ توسط Igor Sysoev ساخته شد و امروز بیش از ۳۴ درصد از وب‌سرورهای دنیا از آن استفاده می‌کنند.

دلیل محبوبیتش ساختار event-driven آن است. برخلاف Apache که برای هر درخواست یک thread جدید باز می‌کند، Nginx می‌تواند هزاران اتصال همزمان را با منابع کم مدیریت کند.

گزینه‌های دیگری مثل Apache، Caddy، Traefik و HAProxy هم وجود دارند که هرکدام کاربرد خودشان را دارند. اما Nginx به دلیل پرفورمنس بالا، مستندات غنی و جامعه بزرگ، رایج‌ترین انتخاب برای محیط‌های پروداکشن است.

راه‌اندازی عملی: از صفر تا پروداکشن

محیط ما

فرض می‌کنیم یک سرور Ubuntu 22.04 داریم و می‌خواهیم:

• یک اپ Node.js روی پورت 3000 داریم

• یک اپ Python/FastAPI روی پورت 8000 داریم

• دامنه example.com را داریم

• می‌خواهیم SSL داشته باشیم

• می‌خواهیم استاتیک فایل‌ها بهینه سرو شوند

مرحله اول: نصب Nginx

sudo apt update
sudo apt install nginx -y

# بررسی وضعیت سرویس
sudo systemctl status nginx

# اگر اجرا نیست:
sudo systemctl start nginx
sudo systemctl enable nginx

بعد از نصب، با رفتن به آدرس IP سرور باید صفحه پیش‌فرض Nginx را ببینید.

مرحله دوم: آشنایی با ساختار فایل‌های Nginx

/etc/nginx/
├── nginx.conf              ← فایل اصلی تنظیمات
├── sites-available/        ← تنظیمات سایت‌ها (غیرفعال)
├── sites-enabled/          ← تنظیمات فعال (لینک به sites-available)
├── conf.d/                 ← فایل‌های تنظیمات اضافی
└── snippets/               ← قطعه‌های قابل استفاده مجدد

فلسفه کار این است که تنظیمات را در sites-available می‌نویسید و با یک symlink در sites-enabled فعالشان می‌کنید. این باعث می‌شود بتوانید سایت‌ها را راحت فعال و غیرفعال کنید.

مرحله سوم: اولین تنظیم ریورس پراکسی

یک فایل تنظیمات برای اپ Node.js بسازیم:

sudo nano /etc/nginx/sites-available/myapp

server {
    listen 80;
    server_name example.com www.example.com;

    # لاگ‌های اختصاصی این سایت
    access_log /var/log/nginx/myapp_access.log;
    error_log /var/log/nginx/myapp_error.log;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        
        # هدرهای ضروری برای ریورس پراکسی
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        
        # برای WebSocket اگر استفاده می‌کنید
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_cache_bypass $http_upgrade;
    }
}

حالا آن را فعال می‌کنیم:

sudo ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/

# بررسی صحت تنظیمات - این دستور را قبل از هر reload اجرا کنید
sudo nginx -t

# اعمال تغییرات
sudo systemctl reload nginx

چرا آن هدرها ضروری هستند؟

• proxy_set_header Host $host: بدون این، سرور اصلی نمی‌داند درخواست برای کدام دامنه آمده.

• X-Real-IP و X-Forwarded-For: چون ریورس پراکسی جلوی سرور است، IP کلاینت در سرور اصلی به درستی نمایش داده نشده است. این هدرها IP واقعی کاربر را انتقال می‌دهند.

• X-Forwarded-Proto: به سرور اصلی می‌گوید کلاینت با HTTP آمده یا HTTPS. بدون این، اگر HTTPS داشته باشید و redirect تولید کنید، ممکن است loop ایجاد شود.

مرحله چهارم: مدیریت چند سرویس

حالا فرض کنید می‌خواهید هم اپ Node.js و هم اپ Python داشته باشید، هر کدام زیر یک مسیر مختلف:

server {
    listen 80;
    server_name example.com;

    # مسیر اصلی به Node.js می‌رود
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # مسیر /api به FastAPI می‌رود
    location /api/ {
        proxy_pass http://localhost:8000/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # فایل‌های استاتیک مستقیم از Nginx سرو می‌شوند
    location /static/ {
        root /var/www/myapp;
        expires 30d;
        add_header Cache-Control "public, immutable";
    }
}

یک نکته مهم: توجه به slash آخر در proxy_pass http://localhost:8000/ مهم است. وقتی slash دارد، مسیر /api/users به /users تبدیل می‌شود. اگر slash نباشد، به /api/users ارسال می‌شود.

مرحله پنجم: SSL با Certbot

# نصب certbot
sudo apt install certbot python3-certbot-nginx -y

# دریافت و نصب خودکار گواهینامه
sudo certbot --nginx -d example.com -d www.example.com

Certbot به صورت خودکار تنظیمات Nginx را برای HTTPS ویرایش می‌کند. بعد از اجرا، فایل تنظیمات شما چیزی شبیه به این خواهد بود:

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    location / {
        proxy_pass http://localhost:3000;
        # ... بقیه هدرها
    }
}

# ریدایرکت HTTP به HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

تجدید خودکار گواهینامه هم از قبل تنظیم شده. می‌توانید با این دستور بررسی کنید:

sudo certbot renew --dry-run

تنظیمات پروداکشن که اغلب نادیده گرفته می‌شوند

بهینه‌سازی فایل اصلی nginx.conf

# /etc/nginx/nginx.conf

user www-data;

# معمولاً برابر با تعداد هسته‌های CPU
worker_processes auto;

events {
    # حداکثر اتصال همزمان هر worker
    worker_connections 1024;
    use epoll;
    multi_accept on;
}

http {
    # پنهان کردن نسخه Nginx در هدرها
    server_tokens off;
    
    # بهینه‌سازی ارسال فایل
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    
    # فشرده‌سازی پاسخ‌ها
    gzip on;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml;
    gzip_min_length 1000;
    gzip_vary on;
    
    # timeoutهای مناسب
    keepalive_timeout 65;
    client_max_body_size 10M;
    
    # هدرهای امنیتی
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;
    
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

Rate Limiting

جلوگیری از درخواست‌های بیش از حد یک کلاینت:

http {
    # تعریف zone برای rate limiting
    # zone=api: اسم zone
    # 10m: ۱۰ مگابایت حافظه برای ذخیره IPها
    # rate=10r/s: حداکثر ۱۰ درخواست در ثانیه
    limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
    limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
    
    server {
        location /api/ {
            limit_req zone=api burst=20 nodelay;
            proxy_pass http://localhost:3000;
        }
        
        location /login {
            limit_req zone=login burst=3;
            proxy_pass http://localhost:3000;
        }
    }
}

burst=20 یعنی اگر ناگهان ۲۰ درخواست آمد قبول می‌شود، اما بعدش باید به نرخ عادی برگردد.

Load Balancing واقعی

http {
    # تعریف upstream با چند سرور
    upstream nodejs_backend {
        # روش پیش‌فرض: round robin
        server localhost:3000;
        server localhost:3001;
        server localhost:3002;
        
        # keepalive برای بهبود پرفورمنس
        keepalive 32;
    }
    
    # یا با وزن‌دهی (اگر یک سرور قوی‌تر است)
    upstream weighted_backend {
        server server1.internal weight=3;
        server server2.internal weight=1;
    }
    
    # ip_hash: هر کاربر همیشه به یک سرور می‌رود (مفید برای session)
    upstream sticky_backend {
        ip_hash;
        server server1.internal;
        server server2.internal;
    }
    
    server {
        location / {
            proxy_pass http://nodejs_backend;
            proxy_http_version 1.1;
            proxy_set_header Connection "";
        }
    }
}

Caching برای API

http {
    # تعریف cache zone
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api_cache:10m 
                     max_size=1g inactive=60m use_temp_path=off;
    
    server {
        location /api/public/ {
            proxy_cache api_cache;
            proxy_cache_valid 200 10m;
            proxy_cache_valid 404 1m;
            
            # هدری که نشان می‌دهد پاسخ از cache آمده یا نه
            add_header X-Cache-Status $upstream_cache_status;
            
            proxy_pass http://localhost:3000;
        }
    }
}

یک سناریوی کامل پروداکشن

بگذارید همه چیز را در یک تنظیم واقعی کنار هم بگذاریم. فرض می‌کنیم یک استارتاپ داریم با:

• فرانت‌اند React (فایل استاتیک)

• بک‌اند Node.js

• سرویس جداگانه برای آپلود فایل

# /etc/nginx/sites-available/startup.com

# Upstream تعریف‌ها
upstream api_backend {
    server localhost:3000;
    server localhost:3001 backup;
    keepalive 16;
}

upstream upload_service {
    server localhost:4000;
}

# Redirect HTTP به HTTPS
server {
    listen 80;
    server_name startup.com www.startup.com;
    return 301 https://$host$request_uri;
}

# سرور اصلی HTTPS
server {
    listen 443 ssl http2;
    server_name startup.com www.startup.com;

    # SSL
    ssl_certificate /etc/letsencrypt/live/startup.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/startup.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;

    # لاگ‌ها
    access_log /var/log/nginx/startup_access.log;
    error_log /var/log/nginx/startup_error.log warn;

    # فایل‌های استاتیک React
    root /var/www/startup/build;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
        expires 1h;
        add_header Cache-Control "public";
    }

    # فایل‌های استاتیک با cache طولانی
    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }

    # API
    location /api/ {
        limit_req zone=api burst=30 nodelay;

        proxy_pass http://api_backend/;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Timeout مناسب برای API
        proxy_connect_timeout 5s;
        proxy_read_timeout 60s;
        proxy_send_timeout 60s;
    }

    # آپلود فایل (timeout بیشتر)
    location /upload/ {
        client_max_body_size 50M;
        proxy_read_timeout 300s;

        proxy_pass http://upload_service/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # WebSocket
    location /ws/ {
        proxy_pass http://api_backend/ws/;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_read_timeout 86400s;
    }
}

دیباگ و عیب‌یابی

دستورات مفید

# بررسی صحت تنظیمات
sudo nginx -t

# reload بدون قطع اتصالات فعال
sudo systemctl reload nginx

# بررسی لاگ‌های خطا به صورت real-time
sudo tail -f /var/log/nginx/error.log

# بررسی اتصالات فعال
sudo nginx -s status

# نمایش تنظیمات کامل بعد از include
sudo nginx -T

# بررسی اینکه کدام فایل تنظیمات اعمال شده
sudo nginx -T | grep server_name

خطاهای رایج

• 502 Bad Gateway: سرور اصلی در دسترس نیست یا crash کرده. ابتدا بررسی کنید آیا سرویس روی پورت مورد نظر اجرا است:

  curl http://localhost:3000/health
  netstat -tlnp | grep 3000
  

  کپی

• 504 Gateway Timeout: درخواست خیلی طول کشیده. proxy_read_timeout را افزایش دهید یا مشکل سرور اصلی را پیدا کنید.

• 413 Request Entity Too Large: client_max_body_size را افزایش دهید.

• WebSocket کار نمی‌کند: هدرهای Upgrade و Connection را بررسی کنید.

Nginx در برابر رقبا

Nginx در برابر Apache

Apache مدل process-based دارد و برای هر اتصال یک thread باز می‌کند. این در ترافیک بالا منابع زیادی مصرف می‌کند. Nginx با مدل event-driven چندین هزار اتصال را با یک worker process مدیریت می‌کند. اما Apache مزیت‌هایی هم دارد: .htaccess که اجازه می‌دهد تنظیمات در سطح دایرکتوری تعریف شوند، و پشتیبانی بهتر از برخی فناوری‌های قدیمی مثل mod_php.

Nginx در برابر Caddy

Caddy یک رقیب جدیدتر است که SSL را به صورت خودکار مدیریت می‌کند. تنظیمات آن ساده‌تر است اما کانفیگ Nginx انعطاف و کنترل بیشتری می‌دهد. برای تیم‌های کوچک که می‌خواهند سریع راه بیافتند، Caddy گزینه خوبی است.

Nginx در برابر Traefik

Traefik برای محیط‌های container-native (Kubernetes، Docker Swarm) طراحی شده و کشف خودکار سرویس‌ها را پشتیبانی می‌کند. اگر با Kubernetes کار می‌کنید، Traefik یا ingress-nginx انتخاب‌های بهتری هستند.

مزایا و معایب این رویکرد

مزایا

ریورس پراکسی لایه‌ای از انتزاع بین کاربر و زیرساخت ایجاد می‌کند. می‌توانید سرورهای پشتی را بدون اطلاع کاربر تغییر دهید. SSL در یک جا مدیریت می‌شود. پرفورمنس بهتری برای فایل‌های استاتیک دارید. امنیت بیشتری دارید چون سرورهای اصلی مستقیم در معرض اینترنت نیستند.

معایب

یک لایه پیچیدگی اضافه می‌شود. دیباگ کردن مشکلات شبکه کمی سخت‌تر می‌شود چون باید مطمئن شوید مشکل از Nginx است یا سرویس پشتی. اگر Nginx crash کند، همه چیز از کار می‌افتد (که با high availability می‌توان حل کرد).

جمع‌بندی

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

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

نظر شخصی: اگر تازه شروع می‌کنید، با یک تنظیم ساده شروع کنید و کم‌کم گسترش دهید. سعی نکنید از ابتدا همه چیز را کامل کنید. اما حتماً از همان ابتدا SSL داشته باشید و هدرهای پراکسی را درست تنظیم کنید، این دو مورد را نمی‌توانید بعداً راحت اضافه کنید بدون اینکه کارها خراب شود.

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

آیا می‌توانم بدون Nginx هم اپلیکیشن را deploy کنم؟ بله، می‌توانید اپلیکیشن را مستقیم روی پورت 80 یا 443 اجرا کنید. اما در عمل این کار مشکلاتی دارد: SSL مدیریت کردن سخت‌تر است، نمی‌توانید چند سرویس روی یک IP داشته باشید، و پرفورمنس سرو فایل‌های استاتیک کمتر است.

تفاوت proxy_pass http://localhost:3000 و proxy_pass http://localhost:3000/ چیست؟ وقتی slash آخر هست، مسیر از URL حذف می‌شود. مثلاً location /api/ با proxy_pass http://localhost:3000/ یعنی /api/users به /users تبدیل می‌شود. بدون slash، مسیر کامل منتقل می‌شود.

چطور بفهمم Nginx درست کانفیگ شده؟ با دستور sudo nginx -t صحت syntax را بررسی کنید. بعد با ابزاری مثل curl -v هدرهای پاسخ را بررسی کنید و ببینید هدر Server چه می‌گوید و هدرهایی که تنظیم کرده‌اید وجود دارند یا نه.

آیا Nginx برای WebSocket مناسب است؟ بله، اما باید هدرهای Upgrade و Connection را تنظیم کنید و proxy_read_timeout را بالا ببرید چون اتصالات WebSocket طولانی‌مدت هستند.

چطور یک سرور Nginx را بدون downtime ریستارت کنم؟ از sudo systemctl reload nginx یا sudo nginx -s reload استفاده کنید. این دستورها کانفیگ جدید را بارگذاری می‌کنند بدون اینکه اتصالات فعال قطع شوند.

آیا Nginx می‌تواند جایگزین یک load balancer سخت‌افزاری شود؟ برای اکثر پروژه‌ها بله. Nginx در محیط‌هایی با صدها هزار درخواست در ثانیه هم به خوبی کار می‌کند. تنها در مقیاس‌های بسیار بزرگ (میلیون‌ها درخواست در ثانیه) ممکن است به راه‌حل‌های تخصصی‌تر نیاز باشد.

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

این دقیقاً همان اتفاقی است که برای خانواده Claude Mythos افتاد.

در ۹ ژوئن ۲۰۲۶، Anthropic از دو مدل جدید به نام‌های Claude Fable 5 و Claude Mythos 5 رونمایی کرد. این معرفی، اوج یک فرآیند چند ماهه بود که از آوریل همان سال آغاز شده بود — زمانی که Anthropic برای اولین بار ثابت کرد مدل‌های هوش مصنوعی می‌توانند به مرزهایی برسند که انتشار بی‌قید و شرط آن‌ها دیگر گزینه‌ای مطمئن نیست.

در این مقاله، با تکیه بر اعلامیه رسمی Anthropic، تمام جوانب این دو مدل را بررسی می‌کنیم.

پیش‌زمینه: داستان Mythos Preview

برای درک Fable 5 و Mythos 5، باید به آوریل ۲۰۲۶ برگردیم.

در آن ماه، Anthropic اولین مدل از خانواده Mythos-class خود را با نام Claude Mythos Preview معرفی کرد. اما برخلاف تمام مدل‌های قبلی، این مدل به صورت عمومی منتشر نشد. دلیل آن چیز غیرمنتظره‌ای بود: Mythos Preview توانسته بود آسیب‌پذیری‌هایی در سیستم‌عامل‌ها و مرورگرهای اصلی شناسایی کند — بدون اینکه اصلاً برای این هدف طراحی شده باشد.

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

Anthropic در پاسخ به این وضعیت، پروژه‌ای به نام Project Glasswing راه‌اندازی کرد: یک برنامه همکاری کنترل‌شده با سازمان‌های منتخب، از جمله Apple، Google، Amazon، Microsoft، Cisco، JPMorgan Chase و دولت ایالات متحده. هدف این پروژه استفاده از توانایی‌های Mythos برای تقویت امنیت زیرساخت‌های حیاتی بود — نه بهره‌برداری از آن برای حمله.

چند هفته بعد، Anthropic دسترسی را به حدود ۱۵۰ سازمان در بیش از پانزده کشور گسترش داد. و حالا، با معرفی Fable 5، برای اولین بار این فناوری در اختیار عموم قرار گرفته است.

Claude Fable 5 چیست؟

Claude Fable 5 اولین مدل Mythos-class است که برای همه کاربران در دسترس قرار گرفته. Anthropic درباره آن صریح است: «توانایی‌های Fable 5 از هر مدلی که تا به حال به صورت عمومی عرضه کرده‌ایم فراتر می‌رود.»

اما این قدرت بیشتر با یک مکانیزم امنیتی همراه شده است. Fable 5 از سیستمی به نام classifier استفاده می‌کند — مجموعه‌ای از مدل‌های هوش مصنوعی جداگانه که درخواست‌های بالقوه مخرب را شناسایی می‌کنند. هر بار که این سیستم یک درخواست را مشکل‌دار تشخیص دهد، پاسخ به‌طور خودکار توسط Claude Opus 4.8 داده می‌شود — به جای اینکه درخواست کاملاً رد شود. این رویکرد هوشمندانه‌ای است؛ چرا که کاربر یک پاسخ مفید دریافت می‌کند، اما از توانایی‌های پیشرفته‌تری که می‌توانند مورد سوءاستفاده قرار بگیرند، محافظت می‌شود.

این fallback در کمتر از ۵ درصد جلسات اتفاق می‌افتد. برای بقیه کاربران، عملکرد Fable 5 عملاً برابر با Mythos 5 است.

سه حوزه اصلی تحت پوشش classifier قرار دارند:

امنیت سایبری. Mythos-class در شناسایی و بهره‌برداری از آسیب‌پذیری‌های نرم‌افزاری فوق‌العاده عمل می‌کند. classifier های Fable 5 نه‌تنها بهره‌برداری از آسیب‌پذیری، بلکه طیف گسترده‌تری از وظایف تهاجمی سایبری — شامل شناسایی، حرکت جانبی و فرار از سیستم‌های دفاعی — را پوشش می‌دهند. یک آزمون خارجی با بیش از ۱۰۰۰ ساعت تست انجام شد و هیچ jailbreak جهانی پیدا نشد.

زیست‌شناسی و شیمی. Mythos 5 در پیش‌بینی خواص ویروس‌های پیچیده، عملکردی بهتر از مدل‌های اختصاصی پروتئین داشت — بدون اینکه برای این کار آموزش دیده باشد. این توانایی dual-use است: در دست محققان، ابزاری ارزشمند برای توسعه درمان‌های ژنی است؛ در دست افراد نادرست، می‌تواند خطرناک باشد. به همین دلیل، اکثر درخواست‌های مرتبط با زیست‌شناسی و شیمی فعلاً به Opus 4.8 ارجاع داده می‌شوند.

Distillation. این classifier از تلاش‌های مقیاس‌بزرگ برای استخراج توانایی‌های Claude و استفاده از آن‌ها برای آموزش مدل‌های رقیب جلوگیری می‌کند.

Claude Mythos 5 چیست؟

Claude Mythos 5 همان مدل پایه‌ای است که Fable 5 بر آن بنا شده، اما با یک تفاوت کلیدی: محدودیت‌های سایبری آن برداشته شده است.

نام‌گذاری این دو مدل نیز بامعناست. «Fable» از ریشه لاتین fabula به معنای «آنچه گفته می‌شود» می‌آید — هم‌ریشه با کلمه یونانی mythos. تنها چیزی که این دو مدل را از هم جدا می‌کند، وجود یا عدم وجود همان safeguardها است.

Mythos 5 در حال حاضر تنها برای شرکای Project Glasswing — شامل سازمان‌های امنیت سایبری و ارائه‌دهندگان زیرساخت‌های حیاتی — در دسترس است. Anthropic قصد دارد به زودی دسترسی را به محققان زیست‌پزشکی تأییدشده نیز گسترش دهد، با این تفاوت که برای آن‌ها safeguardهای زیست‌شناسی برداشته می‌شود، اما محدودیت‌های سایبری همچنان باقی می‌ماند.

قابلیت‌های اصلی این مدل‌ها

Fable 5 و Mythos 5 در چند حوزه به صورت خاص برجسته هستند.

برنامه‌نویسی. شرکت Stripe گزارش داده که Fable 5 یک migration در پایگاه کد ۵۰ میلیون خطی Ruby را در یک روز انجام داد — کاری که یک تیم کامل بیش از دو ماه نیاز داشت. در بنچمارک FrontierCode که کیفیت کد تولیدی در محیط‌های واقعی را ارزیابی می‌کند، Fable 5 بالاترین امتیاز را در بین مدل‌های frontier کسب کرد.

وظایف طولانی‌مدت. این مدل‌ها می‌توانند ساعت‌ها روی یک پروژه کار کنند، پیشرفت خود را ارزیابی کنند و مسیر را در صورت نیاز اصلاح کنند. هر دو مدل از پنجره context یک میلیون توکن با خروجی تا ۱۲۸ هزار توکن در هر درخواست پشتیبانی می‌کنند. آزمایش با بازی Slay the Spire نشان داد که استفاده از حافظه مبتنی بر فایل، عملکرد Fable 5 را سه برابر بیشتر از Opus 4.8 بهبود می‌دهد.

پردازش تصویر. Fable 5 جدیدترین مدل state-of-the-art در حوزه بینایی است. این مدل توانست بازی Pokémon FireRed را تنها با تماشای اسکرین‌شات‌های خام و بدون هیچ ابزار کمکی به پایان برساند — کاری که مدل‌های قبلی Claude حتی با harness های پیچیده هم به سختی از پس آن برمی‌آمدند.

تحقیقات علمی. Mythos 5 فرآیند طراحی دارو را تا ۱۰ برابر سریع‌تر کرده و در ۹ مورد از ۱۴ هدف پروتئینی مورد مطالعه، کاندیداهای قوی شناسایی کرده است. همچنین اولین مدل Anthropic است که به طور مستمر فرضیه‌های علمی نوآورانه تولید می‌کند؛ یکی از این فرضیه‌ها درباره یک پروتئین باکتریایی بعداً توسط یک آزمایشگاه مستقل تأیید شد.

تحلیل مالی و کاری. در Finance Benchmark شرکت Hebbia برای استدلال در سطح ارشد، Fable 5 بالاترین امتیاز را در بین تمام مدل‌های آزمایش‌شده کسب کرد. شرکت IMC نیز گزارش داد که این مدل در تقریباً تمام معیارهای ارزیابی تحلیل معاملاتی نتایج عالی داشت.

سیاست جدید نگهداری داده

یکی از تغییرات مهمی که با این مدل‌ها همراه شده، الزام نگهداری ۳۰ روزه داده برای تمام ترافیک روی مدل‌های Mythos-class است.

Anthropic تأکید می‌کند که این داده‌ها برای آموزش مدل‌های جدید استفاده نمی‌شوند و تمام دسترسی‌های انسانی به آن‌ها ثبت می‌شود. هدف اصلی شناسایی jailbreak های پیچیده‌ای است که ممکن است در طول زمان و در چند مکالمه مختلف طراحی شده باشند — حملاتی که بررسی تک‌به‌تک جلسات قادر به شناسایی آن‌ها نیست.

قیمت‌گذاری و دسترسی

هر دو مدل با قیمت یکسان عرضه شده‌اند: ۱۰ دلار به ازای هر میلیون توکن ورودی و ۵۰ دلار به ازای هر میلیون توکن خروجی. این قیمت کمتر از نصف قیمت Claude Mythos Preview است.

از نظر دسترسی:

Claude Fable 5 از ۹ ژوئن ۲۰۲۶ از طریق Claude API و پلن‌های Enterprise مصرفی کاملاً در دسترس است. برای کاربران اشتراکی (Pro، Max، Team و Enterprise)، این مدل تا ۲۲ ژوئن بدون هزینه اضافه در دسترس است. از ۲۳ ژوئن، استفاده از آن نیاز به usage credit خواهد داشت. Anthropic اعلام کرده که به محض کافی شدن ظرفیت، Fable 5 را دوباره به‌عنوان بخش استاندارد پلن‌های اشتراکی اضافه خواهد کرد.

Claude Mythos 5 فعلاً تنها در اختیار شرکای Project Glasswing است و به زودی برای محققان زیست‌پزشکی تأییدشده نیز باز خواهد شد.

جمع‌بندی

Claude Fable 5 و Mythos 5 را می‌توان مهم‌ترین معرفی Anthropic در سال ۲۰۲۶ دانست — نه فقط به خاطر قدرت بیشتر، بلکه به خاطر رویکردی که پشت آن‌هاست.

برای اولین بار، یک شرکت هوش مصنوعی به جای اینکه یک مدل را به خاطر نگرانی‌های امنیتی کنار بگذارد یا بدون هیچ محدودیتی آن را منتشر کند، مسیر سومی را انتخاب کرد: انتشار با safeguardهای دقیق، ارجاع هوشمند به جای رد کردن، آزمون‌های امنیتی گسترده، و گسترش تدریجی دسترسی بر اساس اعتماد.

این الگو نشان‌دهنده بلوغ صنعتی است — و احتمالاً در مدل‌های آینده نیز استاندارد خواهد شد.

منبع: اعلامیه رسمی Anthropic، ۹ ژوئن ۲۰۲۶

اگر با Docker کار کرده باشی، احتمالاً صدها بار این دستورات را تایپ کرده‌ای:

docker ps
docker logs my-container
docker restart my-container
docker compose up -d

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

اینجاست که Portainer وارد می‌شود.

Portainer دقیقاً چیست؟

Portainer یک پنل مدیریتی تحت وب برای Docker است که همه کارهای رایج را در یک داشبورد گرافیکی ساده قرار می‌دهد. به‌جای اینکه برای هر کار SSH بزنی و دستور تایپ کنی، از مرورگرت وارد می‌شوی و همه‌چیز را یکجا می‌بینی.

علاوه بر Docker، از Kubernetes، Docker Swarm و Podman هم پشتیبانی می‌کند.

جالب اینجاست که خودِ Portainer هم به‌صورت یک Docker Container اجرا می‌شود.

با Portainer چه کارهایی می‌توانی انجام دهی؟

• مشاهده وضعیت کانتینرهای در حال اجرا
• خواندن لاگ‌های هر سرویس مستقیم از مرورگر
• ورود به Shell کانتینر بدون نیاز به exec -it
• ساخت، حذف و ری‌استارت کانتینرها
• مدیریت Volume ها و Network ها
• اجرای Docker Compose Stack ها
• مدیریت چندین سرور Docker از یک پنل واحد
• مدیریت Image ها و پاک‌سازی فضا

رایگان است یا پولی؟

Portainer Community Edition (CE) کاملاً رایگان و متن‌باز است و برای اکثر توسعه‌دهندگان بیش از کافی است.

اگر می‌خواهی کانتینر اجرا کنی، لاگ بخوانی، Docker Compose مدیریت کنی و اپلیکیشن Deploy کنی، نسخه CE کاملاً کافی است.

نصب روی VPS در کمتر از یک دقیقه

اگر Docker روی سرورت نصب است، با همین دستورات Portainer را راه‌اندازی کن:

docker volume create portainer_data

docker run -d \
  --name portainer \
  --restart unless-stopped \
  -p 127.0.0.1:9443:9443 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v portainer_data:/data \
  portainer/portainer-ce:latest

بعد از اجرا از مرورگر وارد شو:

https://YOUR_SERVER_IP:9443

نکته امنیتی: هرگز Portainer را مستقیم روی پورت عمومی اجرا نکن. حتماً پشت Nginx با HTTPS قرار بده و پورت ۹۴۴۳ را از Firewall مسدود کن.

برای چه کسانی مناسب است؟

• توسعه‌دهندگانی که VPS یا سرور شخصی دارند
• کسانی که سرویس‌هایی مثل PostgreSQL، Redis، MinIO یا Grafana را Self-host می‌کنند
• تازه‌کارهایی که دارند Docker یاد می‌گیرند و می‌خواهند وضعیت کانتینرها را بصری ببینند
• فریلنسرها و تیم‌های کوچکی که باید چند پروژه روی یک سرور مدیریت کنند

Portainer جایگزین CLI می‌شود؟

نه، و نباید باشد. Portainer یک ابزار مکمل است، نه جایگزین. برای مدیریت روزمره و مانیتورینگ عالی است، اما برای کارهای پیشرفته‌تر مثل دیباگ مشکلات شبکه، نوشتن Compose فایل‌های پیچیده یا Scripting، همچنان به CLI نیاز داری.

توصیه: هر دو را یاد بگیر. CLI برای تسلط واقعی ضروری است، Portainer برای مدیریت راحت‌تر روزانه.

جمع‌بندی

Portainer یک ابزار رایگان، سریع و کاربرپسند برای مدیریت Docker است. اگر سرور یا VPS داری، نصب Portainer یکی از اولین کارهایی است که باید انجام دهی. در کمتر از یک دقیقه نصب می‌شود و از همان لحظه مدیریت کانتینرهایت را متحول می‌کند.