SSD Nodes Learn Hosting plans →
Hướng dẫn Matt ConnorBởi Matt Connor

Open WebUI hay lựa chọn nào tốt cho VPS?

So sánh Open WebUI, LibreChat, Hollama và OrionChat trên VPS public IP: RAM còn lại cho model, login, Ollama từ xa và công sức bảo trì.

Lựa chọn thay thế Open WebUI nào phù hợp với VPS

Các lựa chọn thay thế Open WebUI gần như luôn được so sánh trên laptop, nơi RAM có giá rẻ và không có dịch vụ nào lắng nghe trên địa chỉ public. VPS làm thay đổi cả hai điều này, nên thứ hạng cũng thay đổi. Open WebUI vẫn là lựa chọn mặc định phù hợp ngay khi có người thứ hai đăng nhập, vì nó cung cấp sẵn tài khoản người dùng thực và admin panel. Các dự án nhẹ hơn có lợi thế khi giao diện phải cạnh tranh với model cho từng gigabyte RAM cuối cùng. Đổi lại, chúng không có authentication.

Toàn bộ nội dung dưới đây lấy từ tài liệu riêng của từng dự án, được đọc vào tháng 8 năm 2026, kiểm tra lại vào ngày 20 tháng 10 năm 2026, rồi kiểm tra thêm lần nữa đối với Open WebUI, LibreChat, Hollama và OrionChat vào ngày 25 tháng 10 năm 2026. Tài liệu của Ollama và các quy tắc bảo mật của trình duyệt được kiểm tra lại vào ngày 29 tháng 10 năm 2026. Bốn tiêu chí này chỉ xuất hiện khi server có thể truy cập từ Internet.

Bốn yếu tố chỉ thực sự quan trọng khi dùng public IP

  • Bộ nhớ dùng chung với model. Model server là tiến trình tốn tài nguyên nhất trên máy. Mỗi megabyte mà interface sử dụng là một megabyte model không thể sử dụng.
  • Xác thực. Một số project có user account và role. Một số project khác giả định chúng là ứng dụng duy nhất chạy trên laptop của bạn và hoàn toàn không có login.
  • Inference từ xa. Một UI chỉ luôn trỏ đến 127.0.0.1:11434 giả định model chạy trên cùng máy với interface. Nếu đặt model ở nơi khác, bạn cần một tunnel chuyển tiếp local port đó đến host chạy model.
  • Công việc bảo trì. Một container dùng một file SQLite là một loại công việc khác hoàn toàn so với 6 container có MongoDB và vector database phía sau.

Model để lại bao nhiêu RAM cho interface

Interface không phải thành phần lớn nhất trên máy. Model mới là thành phần chiếm nhiều nhất. Kích thước download được công bố chỉ cho biết mức tối thiểu, vì weights phải được giữ trong RAM khi model trả lời. Mức sử dụng bộ nhớ thực tế cao hơn kích thước download sau khi context cache được cấp phát.

Biểu đồPublished download size of common Ollama models, October 2026
Dữ liệu đằng sau biểu đồ này
[
  {
    "label": "llama3.2:3b",
    "download_gb": "2.0"
  },
  {
    "label": "qwen3:4b",
    "download_gb": "2.5"
  },
  {
    "label": "gemma3:4b",
    "download_gb": "3.4"
  },
  {
    "label": "qwen3:8b",
    "download_gb": "5.2"
  }
]

Đó là các số liệu được các trang thư viện Ollama hiển thị vào ngày 25 October 2026. Đây là kích thước được công bố, không phải số đo thực tế. Trên VPS 4 GB, qwen3:4b với kích thước 2.5 GB chỉ còn dưới 1.5 GB cho hệ điều hành và mọi thành phần khác. Context cache sẽ tiếp tục chiếm thêm bộ nhớ khi cuộc trò chuyện dài lên. Vì vậy, giá trị num_ctx bạn đặt vừa là quyết định về bộ nhớ, vừa là quyết định về chất lượng. qwen3:8b với kích thước 5.2 GB hoàn toàn không chạy được trên máy đó. Đây là tình huống các bài tổng hợp về laptop thường không đề cập. Interface chỉ chiếm vài trăm megabyte cũng có thể quyết định model có chạy được hay không. Nếu bạn đang chọn cấu hình máy cho model lớn hơn nhiều so với các tag này, phép tính cho model 27B trên VPS chỉ dùng CPU cho thấy interface nhanh chóng không còn là yếu tố quyết định.

Hãy đo thực tế thay vì tin bất kỳ con số nào trong bài tổng hợp, kể cả con số này. Chạy docker stats --no-stream sau khi hệ thống đã hoạt động thực tế một giờ, không phải một phút sau khi container khởi động, vì bộ nhớ cần đo được cấp phát khi sử dụng lần đầu. Ollama cũng giải phóng weights sau năm phút không hoạt động. Vì vậy, số đo giữa hai cuộc trò chuyện sẽ thấp hơn mức đỉnh. Tin nhắn tiếp theo sẽ phải nạp lại toàn bộ model, trừ khi bạn giữ model trong bộ nhớ bằng keep_alive.

Open WebUI: vẫn là lựa chọn mặc định khi có nhiều người dùng

Open WebUI chạy từ một image và lưu dữ liệu trong một 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

Lệnh trong README của dự án publish -p 3000:8080, cổng này lắng nghe trên mọi interface. Prefix 127.0.0.1: giữ dịch vụ chỉ trên loopback. Trên VPS, prefix này quan trọng hơn mọi phần khác trong dòng lệnh, vì Docker tự ghi các rule iptables và port đã publish sẽ bỏ qua rule deny của ufw.

Truy cập trang qua tunnel hoặc proxy, cả hai cách đều được mô tả bên dưới, rồi tạo tài khoản đầu tiên. Tài khoản đó sẽ trở thành administrator. Sau đó, tính năng đăng ký sẽ tự tắt cho đến khi admin bật lại New Sign Ups. Các tài khoản đăng ký về sau được tạo với role pending, là giá trị mặc định được tài liệu ghi tại DEFAULT_USER_ROLE. Vì vậy, người lạ truy cập được trang vẫn không thể dùng model của bạn cho đến khi admin phê duyệt tài khoản.

Open WebUI dùng nhiều memory hơn các project bên dưới vì nó có nhiều chức năng hơn. Trang hiệu năng của dự án nêu rõ các thành phần gây tốn tài nguyên. Embedding engine mặc định tải một model sentence-transformers bên trong container, theo tài liệu là khoảng 500 MB hoặc hơn cho mỗi worker process. Đặt RAG_EMBEDDING_ENGINE=ollama sẽ chuyển phần việc đó cho model server mà bạn đã chạy sẵn. AUDIO_STT_ENGINE=webapi tránh tải model speech-to-text cục bộ. Khi dùng SQLite mà DATABASE_POOL_SIZE chưa được đặt, pool sẽ dùng kích thước nội bộ lớn và mỗi connection tự tăng page cache cùng memory map của nó. Vì vậy, trên máy nhỏ hãy đặt DATABASE_POOL_SIZE=8 và DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0. Autocomplete gửi yêu cầu đến model để lấy completion trong khi người dùng vẫn đang nhập. Tính năng này hiện được tắt mặc định (ENABLE_AUTOCOMPLETE_GENERATION có giá trị mặc định là False), nên hãy giữ nguyên như vậy trên máy nhỏ.

LibreChat: nhiều người dùng, kèm một stack phía sau

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

Giao diện hoạt động trên cổng 3080. LibreChat phù hợp khi bạn cần một hệ thống identity thay vì chỉ một login box: tài liệu của dự án mô tả cách đăng nhập bằng LDAP và OAuth2, còn file compose mặc định cũng định nghĩa một admin panel để quản lý user, group và role. Panel này không chạy ngay sau khi cài. Nó từ chối khởi động cho đến khi ADMIN_PANEL_SESSION_SECRET được đặt trong .env. Đây là giá trị bắt buộc dài ít nhất 32 ký tự và không có giá trị mặc định, vì vậy hãy dùng openssl rand -hex 32 để tạo giá trị nếu cần. Panel chạy dưới dạng service riêng, không nằm trong tiến trình LibreChat, cần LibreChat v0.8.5 trở lên, và dự án vẫn đánh dấu tính năng này là preview. Tính năng đó đi kèm một stack.

Biểu đồContainers a default install adds, not counting the model server
Dữ liệu đằng sau biểu đồ này
[
  {
    "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": 5,
    "notes": "api, MongoDB, Meilisearch, pgvector, RAG API"
  }
]

File compose mặc định khởi động 5 service: api, MongoDB, Meilisearch, pgvector, RAG API. Admin panel là service thứ sáu, nằm trong cùng file và tham gia stack sau khi bạn đặt secret cho nó. Không service nào trong số này là model. MongoDB và pgvector đều cần phần memory riêng, và trên máy 4 GB, đó là phần memory mà model cần.

Hai service trong file publish port, và không mapping nào chỉ định bind address: API dùng cổng 3080, còn admin panel dùng cổng 3000 trên host, là giá trị mặc định của ADMIN_PANEL_PORT. Vì vậy, cả hai đều listen trên mọi interface sau khi chạy. Open WebUI ở trên cũng dùng cổng 3000, nên hai service sẽ xung đột trên cùng một máy ngay khi panel được bật. Hãy rebind cả hai vào 127.0.0.1 trong docker-compose.override.yml trước khi đưa stack lên Internet.

Nâng cấp là thao tác git, và đây là phần nhiều người làm sai.

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

git pull sẽ dừng với conflict nếu bạn đã sửa docker-compose.yml đang được git track, khiến quá trình nâng cấp chỉ được áp dụng một phần. Hãy đặt các thay đổi vào docker-compose.override.yml, vì dự án cung cấp file này cho mục đích đó, và giữ secret trong .env. Cả hai file đều không được track, nên git pull sẽ không thay đổi chúng.

Trỏ LibreChat đến model server của bạn bằng custom endpoint trong 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"

Thay model-host bằng address của máy đang chạy Ollama. Trường apiKey phải tồn tại dù Ollama bỏ qua giá trị của trường này, nên dùng placeholder là được. Nếu LibreChat chạy trong Docker còn Ollama chạy trên cùng máy, localhost bên trong container trỏ đến chính container đó, vì vậy hãy dùng host.docker.internal thay thế.

Hollama và OrionChat: trình duyệt thực hiện công việc

Hollama cung cấp một ứng dụng web từ một container nhỏ. Các cuộc trò chuyện được lưu trong storage của trình duyệt, không phải trên server.

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

Phiên bản lệnh trong README sử dụng --rm. Tùy chọn này xóa container khi container dừng, nên giao diện không hoạt động trở lại sau khi reboot.

OrionChat đi xa hơn và hoàn toàn không có server component. Clone repository rồi dùng web server bạn đang chạy để cung cấp thư mục đó, hoặc mở index.html từ disk. API key được lưu trong localStorage của trình duyệt, lịch sử chat nằm trong trình duyệt, và app sẽ xóa các chat cũ nhất khi số lượng vượt quá 512. Địa chỉ Ollama của OrionChat được cố định trong source của app (js/script.js) tại http://localhost:11434, và phần settings không có field để thay đổi địa chỉ này.

Cả hai project đều không có login. Trên laptop, điều đó không có vấn đề gì. Trên VPS, điều đó có nghĩa là bạn không được publish page tại 0.0.0.0, đồng thời còn có một điểm dễ bỏ sót hơn: chính trình duyệt gọi model, không phải server.

Thực tế này quyết định nơi bạn có thể dùng hai app này. Trình duyệt phải truy cập trực tiếp vào Ollama. Với OrionChat, điều đó luôn có nghĩa là localhost:11434 trên máy đang chạy trình duyệt. Vì vậy, trên VPS, SSH tunnel bên dưới là route duy nhất đến model. Hollama coi mọi địa chỉ bạn nhập là base URL của connection, và hướng dẫn self-hosting của app có nói đến trường hợp Ollama server chạy trên thiết bị khác: thêm origin của Hollama vào OLLAMA_ORIGINS ở phía Ollama. Vì vậy, trừ khi forward port qua SSH, Ollama phải listen trên địa chỉ rộng hơn loopback; API của Ollama không yêu cầu login hoặc key. Từ đó có hai quy tắc cho trình duyệt. Một page được serve qua HTTPS không thể gọi endpoint HTTP thuần trên public IP address, và console sẽ in 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.. Loopback có một ngoại lệ riêng: đặc tả Mixed Content chỉ block các URL không có khả năng được xem là đáng tin cậy, còn đặc tả Secure Contexts coi localhost, 127.0.0.0/8 và ::1 là đáng tin cậy, nên cùng page HTTPS đó có thể gọi http://localhost:11434 hoặc http://127.0.0.1:11434. SSH tunnel bên dưới dựa vào ngoại lệ này. Từ version 142, Chrome thêm một bước khi page được mở từ một public site như https://chat.example.com: request từ đó đến địa chỉ loopback hoặc local network sẽ chờ người dùng cho phép local network access trong permission prompt. Chrome cũng miễn kiểm tra mixed content cho các HTTP request đến local-network endpoint đã được kiểm soát bằng permission khi hostname là private IP literal như 192.168.0.1, tên .local, hoặc fetch chỉ định targetAddressSpace: "local". Page bạn mở tại http://localhost qua tunnel đã ở trên loopback, nên permission prompt đó không áp dụng. Call đến bất kỳ origin nào khác sẽ bị từ chối với has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource cho đến khi bạn cho phép origin đó.

Cách được Ollama ghi lại để thay đổi một trong hai setting là dùng 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 bây giờ phải in 0.0.0.0:11434 thay vì 127.0.0.1:11434 như trước. Chỉ thay đổi setting này khi firewall hoặc proxy có authentication đã kiểm soát ai được phép truy cập port, vì port 11434 mở đồng nghĩa với một model server mở, và các mass scanner thường nhanh chóng quét đến một public port mới. SSH tunnel bên dưới loại bỏ hoàn toàn vấn đề này: page khi đó chạy trên một origin localhost, được Ollama cho phép mặc định, và port không bao giờ rời khỏi máy.

Mỗi ứng dụng có dùng được endpoint Ollama hoặc vLLM từ xa không

Open WebUI dùng được, và kết nối được thực hiện phía server. OLLAMA_BASE_URL=http://model-host:11434 trỏ ứng dụng đến Ollama. Với vLLM, đặt OPENAI_API_BASE_URL=http://model-host:8000/v1 và giữ nguyên /v1 mà vLLM dùng để cung cấp API. Chỉ đặt OPENAI_API_KEY nếu server được khởi động kèm key, vì hướng dẫn vLLM của Open WebUI không dùng xác thực trong trường hợp khác. Các server tương thích với OpenAI khác dùng base path theo tài liệu riêng của chúng; path này không phải lúc nào cũng là /v1. OPENAI_API_BASE_URLS chấp nhận nhiều backend, phân tách bằng dấu chấm phẩy.

LibreChat dùng được thông qua baseURL của custom endpoint đã nêu ở trên. Request đó cũng rời khỏi server, nên không áp dụng quy tắc của browser. Cùng một base URL và placeholder key đó cũng hoạt động bên ngoài cửa sổ chat, nên chỉ cần vậy là đủ để trỏ coding agent đến model bạn đã host.

Hollama có thể trỏ đến bất kỳ endpoint nào bạn nhập trong phần settings. Kết nối Ollama của nó có base URL có thể chỉnh sửa, mặc định là http://localhost:11434. Ngoài ra, Hollama cung cấp kết nối tương thích với OpenAI, mặc định là http://localhost:8080/v1, để kết nối đến vLLM. Request rời khỏi browser, nên mọi nội dung trong phần trên đều áp dụng cho kết nối này. OrionChat không thể trỏ đến nơi khác. Các endpoint của nó được hardcode, trong đó Ollama luôn dùng http://localhost:11434/v1/chat/completions. README của OrionChat cho biết request được gửi trực tiếp đến API chính thức của từng provider. Chỉ có thể truy cập Ollama từ xa qua SSH tunnel để khiến nó phản hồi trên port local đó. OrionChat hoàn toàn không có setting cho server vLLM.

Tách interface khỏi model là lợi ích thiết thực nhất của endpoint từ xa. Đặt interface trên một máy nhỏ và model trên máy có đủ memory. Đây cũng là lúc quyết định Ollama hay vLLM nên xử lý request, vì hai công cụ này hoạt động rất khác khi nhiều người cùng lúc gửi request đến model. Nếu model server chưa tồn tại, trước hết hãy chạy Ollama trên VPS. Nếu máy chỉ có CPU, hãy đọc Ollama khác llama.cpp như thế nào trước khi chọn runner.

Không bao giờ public chat UI không có đăng nhập trên 0.0.0.0

Trang hardening của Open WebUI cho biết dự án này được “xây dựng cho các mạng riêng, đáng tin cậy, tương tự những hạ tầng tự host khác như database, container registry và CI server”, đồng thời yêu cầu đặt nó sau VPN hoặc reverse proxy có authentication. Một dự án hoàn toàn không có login ít nhất cũng phải được bảo vệ như vậy.

Hãy kiểm tra những gì đang listening trước khi tin tưởng bất kỳ thành phần nào.

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

Một dòng có nội dung 127.0.0.1:3000 là kết quả cần có. Một dòng có nội dung 0.0.0.0:3000 nghĩa là service đang listen trên mọi địa chỉ, còn Docker mặc định cho phép mọi source IP bên ngoài truy cập port đã publish. Nếu một rule trong chain DOCKER-USER của Docker hoặc firewall của nhà cung cấp không chặn, chat interface của bạn đang nằm trên public internet. Từ chính máy của bạn, việc curl -sI http://YOUR.VPS.IP:3000 trả lời HTTP/1.1 200 OK sẽ xác nhận điều đó một cách rõ ràng hơn.

Tắt login của Open WebUI bằng WEBUI_AUTH=False chỉ phù hợp với máy một người dùng mà không ai khác có thể truy cập. Tài liệu của dự án cũng nói rằng tùy chọn này chỉ hoạt động trên installation chưa có user nào được đăng ký, nên bạn không thể áp dụng nó cho installation đã có account.

Mẫu một: bind vào loopback và truy cập qua SSH. Publish mọi port trên 127.0.0.1, sau đó forward port cần dùng: ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com, rồi mở http://localhost:3000 trên laptop. Không có port nào được publish nên không thể bị scan. Với OrionChat, forward model port trong cùng command bằng -L 11434:127.0.0.1:11434 và để Ollama trên loopback. Hollama có thể truy cập Ollama trực tiếp, nhưng forward tương tự vẫn giữ Ollama ngoài public internet, nên đây cũng là cách an toàn hơn cho Hollama. Mức độ an toàn của mẫu này chỉ bằng cấu hình SSH của bạn, vì vậy hãy kết hợp với SSH chỉ dùng key và sshd được harden.

Mẫu hai: reverse proxy xác thực trước khi app nhận request. Giữ app trên loopback, để proxy quản lý port 443 và đặt single sign-on ở phía trước. Traefik được điều khiển bằng label của Docker Compose cùng với Authentik làm identity provider cung cấp cho mọi app trên máy một login và một certificate. Khi Open WebUI chạy phía sau TLS (transport layer security), hãy đặt WEBUI_SESSION_COOKIE_SECURE=true và WEBUI_SESSION_COOKIE_SAME_SITE=strict. Đồng thời rút ngắn JWT_EXPIRES_IN so với giá trị mặc định bốn tuần, vì tài liệu Open WebUI cho biết rằng khi không có Redis, sign-out không vô hiệu hóa token: token vẫn dùng được cho đến khi tự hết hạn.

Mẫu hai không bảo vệ được các project chỉ hoạt động trong browser. Proxy đặt trước page không bảo vệ model endpoint, còn request fetch từ page đến hostname khác không gửi kèm session cookie của bạn. Vì vậy, authenticating proxy đặt trước Ollama sẽ trả về redirect đến form login và chat sẽ fail. Hãy route model endpoint dưới cùng hostname với page hoặc dùng mẫu một.

Nên chọn ứng dụng nào

Nếu có người khác ngoài bạn sẽ sử dụng, hãy chạy Open WebUI. Ứng dụng này có tài khoản người dùng thực, người dùng mới sẽ vào hàng đợi chờ phê duyệt, và đội ngũ duy trì có phát hành hướng dẫn hardening để bạn làm theo. Nếu cần LDAP hoặc admin panel, hãy chạy LibreChat, đặt ADMIN_PANEL_SESSION_SECRET nếu muốn có panel, rồi dùng docker stats để xác nhận rằng 5 service của nó, hoặc 6 service nếu có panel, cùng với model của bạn thực sự vừa đủ tài nguyên trước khi phụ thuộc vào ứng dụng này. Nếu chỉ có một người dùng trên một máy nhỏ, nơi model đã chiếm phần lớn RAM, hãy cung cấp Hollama hoặc OrionChat qua SSH tunnel và để trình duyệt giữ state. Lựa chọn sai trên VPS là public bất kỳ ứng dụng nào trong số này trên 0.0.0.0 mà không có login ở phía trước.

FAQ

Open WebUI có an toàn khi expose trực tiếp trên public IP không?

Trang hardening của Open WebUI mô tả đây là phần mềm dành cho mạng riêng và đáng tin cậy, cùng nhóm với database hoặc CI server. Open WebUI có account thực tế. Account đầu tiên trở thành administrator, còn các account tạo sau vẫn ở trạng thái pending cho đến khi được phê duyệt, nên an toàn hơn nhiều so với UI không có login. Tuy vậy, bạn vẫn nên đặt nó sau reverse proxy có TLS và dùng single sign-on nếu có thể. Publish container port là 127.0.0.1:3000:8080 để các iptables rule của Docker không tự mở port này ra internet phía sau bạn.

Open WebUI alternative nào dùng ít RAM nhất trên VPS?

Các lựa chọn chạy trên browser là Hollama và OrionChat, vì application chạy trên client. Server chỉ gửi static file, và OrionChat hoàn toàn không cần application container. Open WebUI giữ một Python process, một database và mặc định là một local embedding model trong memory. Tài liệu ghi nhận riêng embedding model có thể dùng khoảng 500 MB trở lên cho mỗi worker. Hãy xác nhận các con số trên chính máy của bạn bằng docker stats --no-stream, vì chúng thay đổi theo các feature bạn bật.

Các chat UI này có dùng được Ollama server trên host khác không?

Open WebUI và LibreChat có thể dùng, vì server của chúng tạo kết nối nên không áp dụng rule của browser. Đặt OLLAMA_BASE_URL cho Open WebUI, hoặc đặt baseURL trong custom endpoint cho LibreChat. Với vLLM hoặc server tương thích OpenAI khác, dùng OPENAI_API_BASE_URL cùng base path mà server đó cung cấp. Với vLLM, base path là /v1. Chỉ thêm API key nếu server yêu cầu. Hollama cũng có thể trỏ đến bất kỳ địa chỉ nào, nhưng request được gửi từ browser, nên endpoint cũng phải truy cập được từ browser. OrionChat thì không thể: địa chỉ Ollama của nó được hardcode thành http://localhost:11434. Vì vậy, Ollama remote chỉ hoạt động qua SSH tunnel forward port đó.

Tại sao browser chat UI của tôi không truy cập được Ollama?

Gần như mọi trường hợp đều do một trong 2 nguyên nhân. Mặc định Ollama bind vào 127.0.0.1:11434, nên browser trên máy khác không thể truy cập trực tiếp cho đến khi OLLAMA_HOST được thay đổi hoặc SSH tunnel forward port này. Ollama cũng mặc định chấp nhận cross-origin request từ localhost, 127.0.0.1 và 0.0.0.0. Vì vậy, page được serve từ domain của bạn sẽ bị từ chối với No 'Access-Control-Allow-Origin' header is present on the requested resource cho đến khi origin đó được liệt kê trong OLLAMA_ORIGINS. Nếu page dùng HTTPS còn endpoint là HTTP thuần trên public IP, browser sẽ chặn request vì mixed content trước khi Ollama nhận được request. Các địa chỉ loopback (localhost, mọi địa chỉ trong 127.0.0.0/8 như 127.0.0.2, hoặc [::1]) được miễn áp dụng. Chrome cũng miễn chặn HTTP request trong local network khi dùng private IP literal như 192.168.0.1, hostname .local hoặc targetAddressSpace: "local" sau khi được cấp quyền local-network; các yêu cầu CORS của Ollama vẫn phải được đáp ứng. Đặt cả 2 biến trong override của systemctl edit ollama.service, hoặc forward port qua SSH để giải quyết vấn đề này.

Bài viết này có hữu ích không?

#open-webui#librechat#ollama#self-hosted-ai#chat-ui