بهترین جایگزین Open WebUI برای اجرا روی VPS

کدام جایگزین Open WebUI برای یک VPS مناسب است

جایگزین‌های Open WebUI تقریباً همیشه روی لپ‌تاپ مقایسه می‌شوند؛ جایی که رم ارزان است و هیچ سرویسی روی آدرس عمومی گوش نمی‌دهد. یک VPS هر دو واقعیت را تغییر می‌دهد و این موضوع رتبه‌بندی را عوض می‌کند. Open WebUI به محض اینکه نفر دومی وارد سیستم شود، گزینه پیش‌فرض مناسب باقی می‌ماند، زیرا دارای حساب‌های کاربری واقعی و پنل مدیریت است. پروژه‌های سبک‌تر زمانی برنده می‌شوند که رابط کاربری برای آخرین گیگابایت رم با مدل رقابت می‌کند. بهای این پیروزی، احراز هویت است: آن‌ها هیچ‌کدام احراز هویت ندارند.

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

چهار محور حیاتی برای سرویس‌هایی با IP عمومی

• حافظه در کنار مدل. سرور مدل، پرهزینه‌ترین پردازش روی سیستم است. هر مگابایتی که رابط کاربری (interface) اشغال کند، مگابایتی است که مدل نمی‌تواند از آن استفاده کند.
• احراز هویت. برخی از این پروژه‌ها دارای حساب کاربری و نقش هستند. برخی دیگر فرض را بر این می‌گذارند که تنها برنامه در حال اجرا روی لپ‌تاپ شما هستند و هیچ‌گونه سیستم ورود (login) ندارند.
• استنتاج از راه دور (Remote inference). رابط کاربری که فقط می‌تواند به 127.0.0.1:11434 متصل شود، مدل را مجبور می‌کند روی همان سیستمی اجرا شود که رابط کاربری قرار دارد.
• نگهداری. یک کانتینر با یک فایل SQLite، وظیفه‌ای متفاوت از شش کانتینر با MongoDB و یک پایگاه‌داده برداری (vector database) در پشت آن‌ها است.

مدل چه مقدار رم برای رابط کاربری باقی می‌گذارد

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

[
  {
    "label": "llama3.2:3b",
    "download_gb": "2.0"
  },
  {
    "label": "qwen3:4b",
    "download_gb": "2.5"
  },
  {
    "label": "gemma3:4b",
    "download_gb": "3.3"
  },
  {
    "label": "qwen3:8b",
    "download_gb": "5.2"
  }
]

این‌ها ارقامی هستند که صفحات کتابخانه Ollama در اوت 2026 چاپ کرده‌اند. این‌ها حجم‌های منتشرشده هستند، نه اندازه‌گیری‌های دقیق. روی یک VPS با 4 گیگابایت رم، مدل qwen3:4b با حجم 2.5 گیگابایت، کمتر از 1.5 گیگابایت برای سیستم‌عامل و سایر موارد باقی می‌گذارد و با طولانی‌تر شدن گفتگو، حافظه پنهان (context cache) از همین مقدار نیز می‌کاهد. مدل qwen3:8b با حجم 5.2 گیگابایت اصلاً روی آن سرور جا نمی‌شود. این وضعیتی است که بررسی‌های لپ‌تاپ‌ها هرگز به آن نمی‌پردازند و دقیقاً جایی است که یک رابط کاربری چت که چند صد مگابایت اشغال کرده، تعیین می‌کند که آیا مدل اجرا می‌شود یا خیر. اگر در حال انتخاب اندازه سرور برای چیزی فراتر از این برچسب‌ها هستید، محاسبات مربوط به یک مدل 27B روی یک VPS فقط با CPU نشان می‌دهد که چقدر سریع رابط کاربری دیگر عددی نیست که تعیین‌کننده باشد.

به جای اعتماد به هر عددی در بررسی‌ها، از جمله این مورد، اندازه‌گیری کنید. دستور docker stats --no-stream را پس از یک ساعت استفاده واقعی اجرا کنید، نه یک دقیقه پس از شروع کانتینر، زیرا حافظه‌ای که اهمیت دارد در اولین استفاده تخصیص می‌یابد.

Open WebUI: همچنان پیش‌فرض برای بیش از یک کاربر

برنامه Open WebUI از یک image اجرا می‌شود و داده‌های خود را در یک volume واحد نگهداری می‌کند.

docker run -d -p 127.0.0.1:3000:8080 -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

دستوری که در فایل README پروژه آمده است، پورت -p 3000:8080 را منتشر می‌کند که روی تمام رابط‌های شبکه گوش می‌دهد. پیشوند 127.0.0.1: آن را روی loopback محدود می‌کند. در یک VPS، این پیشوند از هر بخش دیگری در آن خط اهمیت بیشتری دارد، زیرا Docker قوانین iptables اختصاصی خود را می‌نویسد و پورت منتشرشده، قوانین deny در ufw شما را نادیده می‌گیرد.

از طریق یک tunnel یا proxy (که هر دو در ادامه توضیح داده شده‌اند) به صفحه دسترسی پیدا کنید و سپس اولین حساب کاربری را بسازید. آن حساب به مدیر (administrator) تبدیل می‌شود. ثبت‌نام‌های بعدی با نقش pending ایجاد می‌شوند که طبق مستندات، پیش‌فرض DEFAULT_USER_ROLE است؛ بنابراین یک غریبه که به صفحه دسترسی پیدا کند، تا زمانی که مدیر او را تأیید نکند، نمی‌تواند از مدل شما استفاده کند.

برنامه Open WebUI نسبت به پروژه‌های زیر، حافظه بیشتری مصرف می‌کند زیرا کارهای بیشتری انجام می‌دهد و صفحه عملکرد (performance) خود برنامه، بخش‌هایی که باعث این هزینه می‌شوند را نام می‌برد. موتور embedding پیش‌فرض، یک مدل sentence-transformers را داخل container بارگذاری می‌کند که طبق مستندات، حدود 500 MB به ازای هر worker process اشغال می‌کند. تنظیم RAG_EMBEDDING_ENGINE=ollama این وظیفه را به سرور مدلی که از قبل اجرا کرده‌اید می‌سپارد. گزینه AUDIO_STT_ENGINE=webapi از بارگذاری یک مدل محلی تبدیل گفتار به متن (speech-to-text) جلوگیری می‌کند. در SQLite، اگر DATABASE_POOL_SIZE تنظیم نشده باشد، pool به یک اندازه داخلی بزرگ بازمی‌گردد و هر اتصال، page cache و memory map اختصاصی خود را ایجاد می‌کند؛ بنابراین در یک سیستم کوچک، DATABASE_POOL_SIZE=8 و DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0 را تنظیم کنید. گزینه ENABLE_AUTOCOMPLETE_GENERATION=False از درخواست تکمیل متن از مدل توسط رابط کاربری، در حالی که کاربر هنوز در حال تایپ است، جلوگیری می‌کند.

LibreChat: چندکاربره، به همراه یک stack پشتیبان

git clone https://github.com/danny-avila/LibreChat.git
cd LibreChat
cp .env.example .env
docker compose up -d

رابط کاربری روی پورت 3080 پاسخ می‌دهد. زمانی که به یک سیستم احراز هویت نیاز دارید و نه فقط یک کادر ورود ساده، LibreChat گزینه‌ای است که باید بررسی کنید: این برنامه از ورود LDAP و OAuth2 پشتیبانی می‌کند و یک پنل مدیریت برای کاربران و نقش‌ها به همراه دارد. این قابلیت با یک stack ارائه می‌شود.

[
  {
    "label": "OrionChat",
    "containers": 0,
    "notes": "static files, served by a web server you already run"
  },
  {
    "label": "Hollama",
    "containers": 1,
    "notes": "one container serving a browser app"
  },
  {
    "label": "Open WebUI",
    "containers": 1,
    "notes": "application and SQLite in one image"
  },
  {
    "label": "LibreChat",
    "containers": 6,
    "notes": "api, admin panel, MongoDB, Meilisearch, pgvector, RAG API"
  }
]

فایل compose پیش‌فرض، 6 سرویس را اجرا می‌کند: api, admin panel, MongoDB, Meilisearch, pgvector, RAG API. هیچ‌کدام از آن‌ها مدل نیستند. MongoDB و pgvector هر کدام حافظه اختصاصی خود را می‌طلبند و در یک سرور 4 گیگابایتی، این همان حافظه‌ای است که مدل به آن نیاز داشت.

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

docker compose down
git pull
docker compose pull
docker compose up -d

git pull در صورت ویرایش فایل‌های ردیابی‌شده docker-compose.yml با تداخل متوقف می‌شود و سپس ارتقا به‌صورت ناقص اعمال می‌گردد. تغییرات خود را در docker-compose.override.yml قرار دهید که پروژه برای همین منظور در نظر گرفته است و اسرار (secrets) را در .env نگه دارید. هر دو فایل ردیابی نمی‌شوند، بنابراین git pull آن‌ها را دست‌نخورده باقی می‌گذارد.

LibreChat را با یک endpoint سفارشی در librechat.yaml به سرور مدل خود متصل کنید.

endpoints:
  custom:
    - name: "Ollama"
      apiKey: "ollama"
      baseURL: "http://model-host:11434/v1/"
      models:
        default: ["llama3.2"]
        fetch: true
      titleConvo: true
      titleModel: "current_model"
      modelDisplayLabel: "Ollama"

عبارت model-host را با آدرس سروری که Ollama روی آن اجرا می‌شود جایگزین کنید. فیلد apiKey باید وجود داشته باشد، حتی اگر Ollama مقدار آن را نادیده بگیرد، بنابراین یک مقدار جایگزین (placeholder) کافی است. اگر LibreChat در Docker اجرا می‌شود و Ollama روی همان ماشین قرار دارد، localhost در داخل کانتینر به معنای خودِ کانتینر است، بنابراین در آنجا از host.docker.internal استفاده کنید.

Hollama و OrionChat: مرورگر کار را انجام می‌دهد

Hollama یک اپلیکیشن مرورگر را از یک کانتینر کوچک ارائه می‌دهد. چت‌ها در حافظه مرورگر شما ذخیره می‌شوند، نه روی سرور.

docker run -d --restart unless-stopped -p 127.0.0.1:4173:4173 --name hollama ghcr.io/fmaclen/hollama:latest

نسخه README این دستور از --rm استفاده می‌کند که کانتینر را پس از توقف حذف می‌کند، بنابراین رابط کاربری پس از reboot دوباره بالا نمی‌آید. در پشت یک reverse proxy، از -e VITE_ALLOWED_HOSTS='chat.example.com' استفاده کنید، زیرا image فقط اجازه استفاده از host localhost را می‌دهد و به درخواست برای هر hostname دیگری، به‌جای اپلیکیشن، خطای blocked-host پاسخ می‌دهد.

OrionChat فراتر می‌رود و اصلاً هیچ جزء سمت سروری ندارد. مخزن را clone کنید و پوشه را با وب‌سروری که از قبل اجرا کرده‌اید سرو کنید، یا index.html را از روی دیسک باز کنید. کلیدهای API در localStorage مرورگر ذخیره می‌شوند، تاریخچه چت در مرورگر باقی می‌ماند و اپلیکیشن پس از عبور تعداد چت‌ها از 512، قدیمی‌ترین آن‌ها را حذف می‌کند.

هیچ‌کدام از این دو پروژه سیستم ورود (login) ندارند، زیرا هیچ‌کدام سروری ندارند که بتواند آن را بررسی کند. روی لپ‌تاپ این موضوع مشکلی ندارد. روی یک VPS به این معنی است که صفحه هرگز نباید روی 0.0.0.0 منتشر شود، و به نکته‌ای اشاره دارد که نادیده گرفتن آن آسان‌تر است: مرورگر است مدل را فراخوانی می‌کند، نه سرور.

همین یک واقعیت تعیین می‌کند که این دو کجا قابل استفاده هستند. مرورگر شما باید مستقیماً به Ollama دسترسی داشته باشد، بنابراین Ollama باید روی چیزی فراتر از loopback گوش دهد و Ollama هیچ‌گونه احراز هویتی ندارد. دو قانون مرورگر از این موضوع ناشی می‌شود. صفحه‌ای که از طریق HTTPS سرو می‌شود نمی‌تواند یک endpoint ساده HTTP را فراخوانی کند و کنسول Mixed Content: The page at 'https://chat.example.com/' was loaded over HTTPS, but requested an insecure resource 'http://203.0.113.10:11434/api/tags'. This request has been blocked. را چاپ می‌کند. فراخوانی به هر origin دیگری با has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource رد می‌شود مگر اینکه آن origin را مجاز کنید.

روش مستند Ollama برای تغییر هر یک از این تنظیمات، استفاده از یک systemd override است.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=https://chat.example.com"

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ss -lntp | grep 11434

ss اکنون باید 0.0.0.0:11434 را چاپ کند، در حالی که قبلاً 127.0.0.1:11434 را چاپ می‌کرد. این تغییر را فقط زمانی اعمال کنید که یک فایروال یا یک proxy احراز هویت‌کننده، کنترل کند چه کسی می‌تواند به پورت دسترسی داشته باشد، زیرا یک پورت 11434 باز، به معنای یک سرور مدل باز است و اسکنرهای انبوه به‌سرعت پورت‌های عمومی جدید را پیدا می‌کنند. SSH tunnel زیر از کل این مسئله جلوگیری می‌کند: صفحه در آن صورت روی یک origin localhost اجرا می‌شود که Ollama به‌طور پیش‌فرض آن را مجاز می‌داند و پورت هرگز از سرور خارج نمی‌شود.

آیا هر کدام می‌توانند از یک endpoint راه دور Ollama یا vLLM استفاده کنند؟

Open WebUI این قابلیت را دارد و اتصال در سمت سرور برقرار می‌شود. OLLAMA_BASE_URL=http://model-host:11434 آن را به سمت Ollama هدایت می‌کند. برای vLLM یا هر سرور دیگری که با OpenAI سازگار است، OPENAI_API_BASE_URL=http://model-host:8000/v1 را با یک OPENAI_API_KEY غیرخالی تنظیم کنید و پسوند /v1 را که الزامی است، حفظ نمایید. OPENAI_API_BASE_URLS چندین backend را که با نقطه-ویرگول از هم جدا شده‌اند، می‌پذیرد.

LibreChat نیز از طریق baseURL مربوط به endpoint سفارشی که در بالا نشان داده شد، این کار را انجام می‌دهد. آن درخواست نیز از سرور خارج می‌شود، بنابراین هیچ قانون مرورگری در اینجا اعمال نمی‌شود. همان base URL و همان کلید جایگزین (placeholder key) خارج از پنجره چت نیز کار می‌کنند، که این تمام چیزی است که برای هدایت یک coding agent به مدلی که از قبل میزبانی کرده‌اید نیاز دارید.

Hollama و OrionChat می‌توانند به هر endpoint که در تنظیماتشان وارد کنید اشاره کنند، اما درخواست از مرورگر شما خارج می‌شود. تمام موارد ذکر شده در بخش قبل، فقط برای آن‌ها صدق می‌کند و نه برای هیچ‌کدام از موارد این بخش.

جداسازی رابط کاربری از مدل، مفیدترین دستاورد استفاده از یک endpoint راه دور است. رابط کاربری را روی یک دستگاه کوچک و مدل را در جایی که حافظه کافی وجود دارد قرار دهید. این همچنین زمانی است که باید تصمیم بگیرید آیا Ollama یا vLLM باید درخواست‌ها را سرویس‌دهی کنند، زیرا رفتار این دو زمانی که چندین نفر همزمان با مدل صحبت می‌کنند، بسیار متفاوت است. اگر سرور مدل هنوز وجود ندارد، با اجرای Ollama روی یک VPS شروع کنید و در یک دستگاه فقط-CPU، پیش از انتخاب runner، نحوه مقایسه Ollama با llama.cpp را مطالعه کنید.

هرگز یک رابط کاربری چت بدون ورود به سیستم را روی 0.0.0.0 منتشر نکنید

صفحهٔ امن‌سازی Open WebUI بیان می‌کند که این پروژه «برای شبکه‌های خصوصی و قابل‌اعتماد ساخته شده است، مشابه سایر زیرساخت‌های self-hosted مانند دیتابیس‌ها، container registryها و سرورهای CI» و به شما توصیه می‌کند آن را پشت یک VPN یا یک reverse proxy با احراز هویت قرار دهید. پروژه‌ای که اصلاً سیستم ورود ندارد، حداقل به همین سطح از مراقبت نیاز دارد.

پیش از آنکه به هر بخشی از آن اعتماد کنید، بررسی کنید چه چیزی در حال گوش دادن (listening) است.

sudo ss -lntp | grep -E ':(3000|3080|4173|11434)'

خطی که 127.0.0.1:3000 را نشان می‌دهد، همان چیزی است که به دنبالش هستید. خطی که 0.0.0.0:3000 را نشان می‌دهد، به این معنی است که رابط چت شما روی اینترنت عمومی قرار دارد. از روی ماشین خودتان، دستور curl -sI http://YOUR.VPS.IP:3000 که پاسخ HTTP/1.1 200 OK را می‌دهد، همین موضوع را صریح‌تر بیان می‌کند.

غیرفعال کردن ورود به سیستم در Open WebUI با WEBUI_AUTH=False، یک تنظیم تک‌کاربره برای ماشینی است که هیچ‌کس دیگری به آن دسترسی ندارد. همچنین این تنظیم برای نصبی که از قبل دارای حساب کاربری است اعمال نمی‌شود و پیام You can't turn off authentication because there are existing users. را نمایش می‌دهد.

الگوی اول: اتصال به loopback و دسترسی از طریق SSH. تمام پورت‌ها را روی 127.0.0.1 منتشر کنید، سپس آنچه نیاز دارید را forward کنید: ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com، و در لپ‌تاپ خود http://localhost:3000 را باز کنید. هیچ چیزی منتشر نمی‌شود، بنابراین هیچ چیزی قابل اسکن نیست. برای Hollama یا OrionChat، پورت مدل را با همان دستور و با -L 11434:127.0.0.1:11434 forward کنید و Ollama را روی loopback باقی بگذارید. قدرت این الگو تنها به اندازهٔ تنظیمات SSH شماست، بنابراین آن را با SSH فقط با کلید و یک sshd امن‌شده همراه کنید.

الگوی دوم: یک reverse proxy که پیش از رسیدن درخواست به برنامه، احراز هویت انجام می‌دهد. برنامه را روی loopback نگه دارید، اجازه دهید proxy مالک پورت 443 باشد و یک سیستم ورود یکپارچه (SSO) در مقابل آن قرار دهید. Traefik که توسط برچسب‌های Docker Compose هدایت می‌شود به همراه Authentik به عنوان ارائه‌دهنده هویت، به هر برنامه روی سرور یک ورود و یک گواهی می‌دهد. با قرار دادن Open WebUI پشت TLS (امنیت لایه انتقال)، WEBUI_SESSION_COOKIE_SECURE=true و WEBUI_SESSION_COOKIE_SAME_SITE=strict را تنظیم کنید. همچنین JWT_EXPIRES_IN را از مقدار پیش‌فرض چهار هفته‌ای آن کوتاه‌تر کنید، زیرا Open WebUI مستند کرده است که بدون Redis، خروج از سیستم (sign-out) توکن را باطل نمی‌کند: توکن تا زمانی که خودبه‌خود منقضی نشود، قابل استفاده باقی می‌ماند.

الگوی دوم پروژه‌هایی که فقط در مرورگر اجرا می‌شوند را نجات نمی‌دهد. یک proxy در مقابل صفحه، از endpoint مدل محافظت نمی‌کند و یک fetch از آن صفحه به یک hostname متفاوت، session cookie شما را حمل نمی‌کند؛ بنابراین proxy احراز هویت در مقابل Ollama با یک redirect به فرم ورود پاسخ می‌دهد و چت با شکست مواجه می‌شود. یا endpoint مدل را تحت همان hostname صفحه مسیریابی کنید، یا از الگوی اول استفاده کنید.

کدام گزینه را انتخاب کنیم

اگر فردی غیر از شما از آن استفاده خواهد کرد، Open WebUI را اجرا کنید. این ابزار دارای سیستم حساب‌های کاربری واقعی است، کاربران جدید در صف تأیید قرار می‌گیرند و توسعه‌دهندگان آن راهنماهای امن‌سازی (hardening) منتشر می‌کنند که می‌توانید از آن‌ها پیروی کنید. اگر به LDAP یا پنل مدیریت نیاز دارید، LibreChat را اجرا کنید و با docker stats تأیید کنید که 6 سرویس آن به همراه مدل شما، پیش از آنکه به آن وابسته شوید، واقعاً در منابع سرور جا می‌شوند. اگر تنها یک کاربر روی یک سرور کوچک هستید که مدل بخش عمده RAM را اشغال کرده است، Hollama یا OrionChat را از طریق SSH tunnel ارائه دهید و اجازه دهید مرورگر وضعیت (state) را حفظ کند. پاسخ اشتباه روی یک VPS، اجرای هر یک از این موارد روی 0.0.0.0 بدون قرار دادن یک لایه احراز هویت در مقابل آن است.

FAQ

آیا قرار دادن Open WebUI مستقیماً روی یک IP عمومی امن است؟

صفحهٔ hardening خودِ این نرم‌افزار، آن را در دسته‌بندی پایگاه‌داده‌ها یا سرورهای CI قرار می‌دهد و تأکید می‌کند که برای شبکه‌های خصوصی و قابل‌اعتماد طراحی شده است. این برنامه دارای سیستم حساب کاربری است و اولین اکانت به عنوان مدیر (administrator) شناخته می‌شود، در حالی که اکانت‌های بعدی تا زمان تأیید، pending باقی می‌مانند؛ بنابراین نسبت به رابط‌های کاربری بدون ورود، بسیار امن‌تر است. با این حال، حتماً آن را پشت یک reverse proxy با TLS قرار دهید و در صورت امکان از single sign-on استفاده کنید. پورت کانتینر را فقط روی 127.0.0.1:3000:8080 منتشر کنید تا قوانین iptables خودِ Docker نتوانند آن را بدون اطلاع شما در معرض اینترنت قرار دهند.

کدام جایگزین Open WebUI روی یک VPS کمترین میزان RAM را مصرف می‌کند؟

گزینه‌های مبتنی بر مرورگر مانند Hollama و OrionChat، زیرا برنامه روی کلاینت اجرا می‌شود. سرور فقط فایل‌های استاتیک را ارسال می‌کند و OrionChat اصلاً به کانتینر اپلیکیشن نیاز ندارد. Open WebUI یک پردازش Python، یک پایگاه‌داده و به‌صورت پیش‌فرض یک مدل embedding محلی را در حافظه نگه می‌دارد که طبق مستندات، فقط برای مدل embedding حدود 500 MB به ازای هر worker مصرف می‌شود. اعداد دقیق را روی سرور خود با docker stats --no-stream بررسی کنید، زیرا با فعال‌سازی قابلیت‌های مختلف، این میزان تغییر می‌کند.

آیا این رابط‌های کاربری چت می‌توانند از یک سرور Ollama روی میزبان دیگری استفاده کنند؟

Open WebUI و LibreChat این قابلیت را دارند و سرور آن‌ها اتصال را برقرار می‌کند، بنابراین هیچ قانون مرورگری در این مورد اعمال نمی‌شود. برای Open WebUI مقدار OLLAMA_BASE_URL و برای LibreChat در یک endpoint سفارشی، مقدار baseURL را تنظیم کنید. برای vLLM یا سایر سرورهای سازگار با OpenAI، از OPENAI_API_BASE_URL به همراه پسوند /v1 و یک API key غیرخالی استفاده کنید. Hollama و OrionChat نیز می‌توانند به هر مقصدی اشاره کنند، اما چون درخواست از مرورگر شما ارسال می‌شود، آن endpoint باید از طریق مرورگر شما نیز در دسترس باشد.

چرا رابط کاربری چت در مرورگر من نمی‌تواند به Ollama متصل شود؟

دو دلیل تقریباً تمام موارد را پوشش می‌دهد. Ollama به‌صورت پیش‌فرض روی 127.0.0.1:11434 گوش می‌دهد، بنابراین مرورگر در دستگاه دیگر تا زمانی که OLLAMA_HOST تغییر نکند، به آن دسترسی نخواهد داشت. همچنین Ollama درخواست‌های cross-origin را فقط از localhost می‌پذیرد، بنابراین صفحه‌ای که از دامنهٔ شما سرو می‌شود با خطای No 'Access-Control-Allow-Origin' header is present on the requested resource رد می‌شود مگر اینکه آن origin در OLLAMA_ORIGINS لیست شده باشد. اگر صفحه HTTPS باشد و endpoint از نوع HTTP باشد، مرورگر پیش از آنکه Ollama درخواست را ببیند، آن را به عنوان mixed content مسدود می‌کند. هر دو متغیر را در یک systemctl edit ollama.service override تنظیم کنید، یا پورت را از طریق SSH فوروارد کنید تا مشکل برطرف شود.