SSD Nodes Learn 🎉 VPS mulai $5.50/bln
Panduan Matt ConnorOleh Matt Connor

API Ollama Tanpa Kata Sandi: 3 Cara Mengamankannya

Server Ollama tidak menyediakan autentikasi. Siapa pun yang mencapai port 11434 dapat menjalankan, mengunduh, dan menghapus model. Ikuti 3 perbaikan berurutan.

API Ollama tidak memiliki kata sandi

API Ollama tidak memiliki autentikasi. Tidak ada pengguna, kata sandi, pemeriksaan kunci, atau allowlist di mana pun pada server yang Anda jalankan. Apa pun yang dapat membuka koneksi TCP ke port 11434 dapat mencantumkan model Anda, menjalankannya, mengunduh model baru, dan menghapus model yang ada.

Dokumentasi resmi menyatakannya dengan jelas: "Tidak diperlukan autentikasi saat mengakses API Ollama secara lokal melalui http://localhost:11434." Kata lokal mencakup seluruh model keamanan. Secara default, Ollama melakukan bind pada 127.0.0.1, sehingga pada laptop, interface loopback berfungsi sebagai kontrol akses. Jika listener tersebut dipindahkan ke alamat publik, kontrol akses itu hilang karena tidak ada penggantinya.

Inilah alasan hal ini penting pada VPS (virtual private server). Konfigurasi default aman. Perubahan pertama yang biasanya dilakukan orang adalah membuka listener agar mesin kedua dapat menggunakan model. Perubahan tersebut sekaligus menghapus semua perlindungan.

Hal yang diungkapkan oleh port terbuka 11434

Semua endpoint. Tidak ada mode hanya-baca dan tidak ada port admin terpisah. Berikut adalah permintaan sebenarnya yang ditujukan ke alamat server, bukan ke localhost:

# List every model on the box
curl http://SERVER_IP:11434/api/tags

# See what is loaded into memory right now
curl http://SERVER_IP:11434/api/ps

# Run a prompt on your hardware
curl http://SERVER_IP:11434/api/generate -d '{"model":"llama3.2","prompt":"Why is the sky blue?"}'

# Write several gigabytes to your disk
curl http://SERVER_IP:11434/api/pull -d '{"model":"llama3.2"}'

# Remove a model
curl -X DELETE http://SERVER_IP:11434/api/delete -d '{"model":"llama3.2"}'

Dalam istilah operasional, ada empat masalah:

  • CPU atau GPU Anda menjalankan inferensi untuk orang lain. Pada paket dengan kuota CPU fair use, beban berkelanjutan berarti kuota Anda digunakan oleh orang lain, dan menjaga biaya beban kerja AI tetap terkendali pada VPS menjadi jauh lebih sulit ketika Anda bukan satu-satunya pemanggil.
  • /api/pull menulis data ke disk Anda. Setiap model berukuran dua hingga empat puluh gigabita. Perulangan pull memenuhi volume, dan disk yang penuh membuat semua service lain pada server gagal, bukan hanya Ollama.
  • Permintaan masuk ke dalam proses Anda dan dicatat. Pada tingkat log default, Ollama hanya mencatat metadata, sehingga yang tercatat adalah endpoint, status, latensi, dan alamat klien, bukan teks prompt. Namun, ini tetap menjadi catatan tentang siapa yang menggunakan server Anda dan untuk tujuan apa. Catatan tersebut tersimpan dalam journal, tanpa Anda memilih untuk mengumpulkannya.
  • /api/delete menghapus model. Untuk mendapatkannya kembali, Anda harus mengunduhnya lagi menggunakan bandwidth Anda sendiri.

Tidak satu pun dari hal ini memerlukan exploit. Ini adalah API terdokumentasi yang berfungsi tepat sesuai desainnya.

Kunci Ed25519 bukan kontrol akses

Cari "Ollama API key" dan Anda akan menemukan dua hal yang berbeda. Keduanya bukan kata sandi untuk server Anda. Memisahkan keduanya menghilangkan sebagian besar kebingungan.

Yang pertama adalah pasangan kunci identitas. Ollama membuat pasangan kunci Ed25519 pada saat pertama kali dijalankan. Di Linux, skrip instalasi membuat pengguna sistem bernama ollama dengan direktori home di /usr/share/ollama, sehingga pasangan kunci tersebut berada di sini:

/usr/share/ollama/.ollama/id_ed25519
/usr/share/ollama/.ollama/id_ed25519.pub

Kunci tersebut digunakan untuk koneksi keluar. ollama signin mendaftarkan bagian publiknya ke akun ollama.com Anda. Kunci ini juga digunakan untuk mengotorisasi Anda saat mengirim model ke registry atau mengambil model privat. Kunci tersebut membuktikan identitas mesin Anda kepada ollama.com. Kunci tersebut tidak meminta autentikasi apa pun dari klien yang terhubung ke mesin Anda. Menghapus, merotasi, atau tidak pernah membuat kunci tersebut tidak mengubah siapa yang dapat memanggil API Anda.

Yang kedua adalah OLLAMA_API_KEY. Variabel tersebut menyimpan kunci yang Anda buat di https://ollama.com/settings/keys. Klien Anda mengirimkannya sebagai Authorization: Bearer $OLLAMA_API_KEY saat memanggil API yang di-host di https://ollama.com/api. Kunci tersebut adalah kredensial untuk layanan mereka dan digunakan oleh Anda sebagai klien. ollama serve Anda sendiri tidak pernah membacanya. Menetapkan OLLAMA_API_KEY pada VPS Anda tidak memasang kata sandi pada VPS tersebut.

Jadi, tidak ada pengaturan yang perlu diaktifkan. Ketiga pertahanan di bawah ini bekerja dengan cara yang sama: buat port tidak dapat dijangkau, lalu letakkan sesuatu di depannya yang melakukan pemeriksaan.

Periksa layanan yang sedang menerima koneksi di server

sudo ss -tlnp | grep 11434

Hasil yang aman menampilkan alamat loopback:

LISTEN 0  4096  127.0.0.1:11434  0.0.0.0:*  users:(("ollama",pid=812,fd=3))

Hasil yang terekspos menampilkan semua antarmuka:

LISTEN 0  4096  0.0.0.0:11434  0.0.0.0:*  users:(("ollama",pid=812,fd=3))

0.0.0.0 berarti semua alamat IPv4 pada mesin, termasuk alamat publik. *:11434 dan [::]:11434 memiliki arti yang sama dengan IPv6.

Sekarang, lakukan konfirmasi dari luar. Jalankan perintah ini di laptop Anda, bukan di server:

curl -m 5 http://YOUR_SERVER_IP:11434/api/version

curl: (28) Connection timed out after 5001 milliseconds adalah hasil yang diharapkan, begitu juga curl: (7) Failed to connect ... Connection refused. Objek JSON yang memuat bidang version berarti seluruh API dapat diakses oleh siapa pun yang memintanya. Pengujian dengan curl di server itu sendiri tidak membuktikan apa pun karena loopback selalu memberikan respons.

Eksposur biasanya terjadi melalui salah satu dari dua cara. Cara pertama adalah perubahan konfigurasi yang dilakukan secara sengaja karena seseorang perlu mengakses model dari mesin kedua:

sudo systemctl edit ollama.service
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

Satu baris tersebut sudah cukup untuk mengekspos layanan. Cara kedua adalah Docker, dan cara ini tidak mengharuskan Anda mengubah apa pun. Cara tersebut memiliki bagian tersendiri di bawah ini.

Pertahanan 1: pertahankan di localhost dan buat tunnel masuk

Gunakan opsi ini terlebih dahulu. Opsi ini tidak memerlukan software baru dan tidak membuat kredensial yang dapat bocor. Port tersebut tidak pernah tersedia pada interface publik, sehingga pemindaian tidak dapat menemukannya.

Tetapkan alamat bind secara eksplisit, bukan mengandalkan nilai default:

sudo systemctl edit ollama.service
[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"

Perintah tersebut menulis /etc/systemd/system/ollama.service.d/override.conf. Terapkan perubahan lalu periksa:

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

ss sekarang seharusnya menampilkan 127.0.0.1:11434. Jika masih menampilkan 0.0.0.0, berarti file drop-in kedua lebih diprioritaskan. Jalankan systemctl cat ollama.service untuk menampilkan unit dan setiap drop-in beserta path-nya, lalu hapus file yang sudah tidak digunakan.

Untuk menggunakan model dari laptop, teruskan port melalui SSH:

ssh -N -L 11434:127.0.0.1:11434 you@your-server

-L 11434:127.0.0.1:11434 membuka port 11434 pada laptop dan mengirimkan semua data yang masuk ke sana ke 127.0.0.1:11434 dari sudut pandang server. -N memberi tahu SSH agar tidak menjalankan perintah remote, sehingga proses tersebut hanya mempertahankan tunnel tetap terbuka. Selama proses itu berjalan, perintah berikut dapat digunakan pada laptop:

curl -s http://localhost:11434/api/tags

Anda akan menemui dua kegagalan. bind [127.0.0.1]:11434: Address already in use berarti laptop menjalankan Ollama sendiri pada port tersebut. Pilih port lokal lain dengan -L 11500:127.0.0.1:11434, lalu arahkan client ke 11500. Balasan kosong melalui tunnel yang berhasil tersambung berarti SSH berfungsi, tetapi Ollama tidak sedang listening pada sisi server. Periksa ss di server sebelum mengubah perintah SSH.

Untuk beberapa mesin client, jaringan privat lebih baik daripada membuat satu tunnel untuk setiap pengguna. Hubungkan mesin-mesin tersebut ke WireGuard atau Tailscale, lalu bind Ollama ke alamatnya pada jaringan tersebut, bukan ke 0.0.0.0:

[Service]
Environment="OLLAMA_HOST=10.8.0.1:11434"

Dengan demikian, port hanya tersedia pada interface yang memerlukan key untuk bergabung. Pendekatan ini juga tetap aman jika terjadi kesalahan firewall, karena aturan yang tidak sengaja mengizinkan akses dari semua jaringan tetap tidak dapat mengekspos listener yang tidak tersedia pada interface publik.

Pertahanan 2: reverse proxy yang memeriksa bearer token

Jika sesuatu di Internet publik harus memanggil model, pertahankan Ollama pada loopback dan tempatkan proxy di depannya. Proxy mengakhiri TLS (transport layer security) dan menolak permintaan tanpa header yang benar. Ollama tetap hanya menerima koneksi dari 127.0.0.1, sehingga proxy menjadi satu-satunya jalur masuk.

Buat token yang valid terlebih dahulu. Jangan membuatnya secara manual:

openssl rand -base64 36

Situs nginx yang memeriksa token tersebut:

map $http_authorization $ollama_ok {
    default                                   0;
    "Bearer PASTE_YOUR_GENERATED_TOKEN_HERE"  1;
}

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

    ssl_certificate     /etc/letsencrypt/live/llm.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/llm.example.com/privkey.pem;

    location = /api/pull   { return 403; }
    location = /api/delete { return 403; }
    location = /api/push   { return 403; }

    location / {
        if ($ollama_ok = 0) { return 401; }

        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host 127.0.0.1:11434;
        proxy_buffering off;
        proxy_read_timeout 600s;
    }
}

Lima baris di dalamnya menjalankan fungsi penting. Masing-masing mencegah kegagalan yang biasanya akan Anda alami.

if di dalam blok location biasanya merupakan ide buruk di nginx, tetapi body dengan panjang tepat return adalah salah satu dari dua bentuk yang berperilaku konsisten, sehingga penggunaan ini aman.

location = /api/pull adalah pencocokan eksak. nginx memprioritaskan pencocokan eksak di atas prefix location /, sehingga ketiga endpoint tersebut ditolak sebelum token diperiksa. Token yang valid hanya memberikan akses ke inference, bukan kemampuan untuk memenuhi disk Anda.

proxy_set_header Host 127.0.0.1:11434; penting karena Ollama memeriksa header Host dan Origin yang masuk. Meneruskan hostname publik proxy secara langsung dapat menghasilkan 403 Forbidden yang berasal dari Ollama, bukan dari nginx. Hal ini menyulitkan proses debugging. OLLAMA_ORIGINS adalah pengaturan lain yang diperlukan oleh client browser yang memerlukan origin tertentu agar diizinkan.

proxy_buffering off; penting karena Ollama mengalirkan responsnya token demi token. Jika buffering aktif, nginx menahan stream tersebut dan mengirimkannya sekaligus pada akhir proses. Akibatnya, client terlihat macet selama seluruh proses generation.

proxy_read_timeout 600s; penting karena nilai default nginx adalah 60 detik. Proses generation yang lama pada CPU dapat dengan mudah melewati batas tersebut. Client menerima 504 Gateway Time-out, dan /var/log/nginx/error.log mencatat upstream timed out (110: Connection timed out) while reading response header from upstream. Permintaan tersebut sebenarnya masih berjalan. nginx menghentikannya.

Muat ulang dan uji kedua jalur:

sudo nginx -t && sudo systemctl reload nginx
curl -s -o /dev/null -w '%{http_code}\n' https://llm.example.com/api/tags
curl -s -H "Authorization: Bearer YOUR_TOKEN" https://llm.example.com/api/tags

Perintah pertama seharusnya mencetak 401. Perintah kedua seharusnya mencetak daftar model Anda. Jika perintah pertama juga mengembalikan daftar model, blok map berada pada scope yang salah. Blok tersebut harus berada pada level http. Letakkan di file dalam /etc/nginx/conf.d/ atau di atas blok server, jangan pernah di dalam server.

Caddy menjalankan fungsi yang sama dengan basic authentication dalam empat baris. Cara ini lebih sesuai untuk client browser daripada bearer token:

llm.example.com {
	basic_auth {
		apiuser PASTE_BCRYPT_HASH_HERE
	}
	reverse_proxy 127.0.0.1:11434
}

Jalankan caddy hash-password untuk menghasilkan hash bcrypt yang diperlukan. Perhatikan jebakan penamaan berikut: directive tersebut bernama basicauth sebelum Caddy v2.8 dan sekarang bernama basic_auth. Karena itu, konfigurasi yang disalin dari panduan lama akan gagal dimuat, dan Caddy akan menyebutkan directive yang tidak dikenalnya.

Apa pun proxy yang Anda pilih, ini adalah satu shared secret untuk semua pengguna. Setiap client yang memilikinya memperoleh akses yang sama. Untuk mencabut akses, Anda harus mengedit konfigurasi dan memperbarui semua pemanggil secara bersamaan.

Pertahanan 3: gateway yang menerbitkan key untuk setiap klien

Setelah lebih dari satu orang atau aplikasi memanggil model, token bersama tidak lagi memadai. Anda tidak dapat mengetahui klien mana yang menyebabkan beban, dan tidak dapat memutus akses salah satu klien tanpa memutus akses semua klien. Gateway ditempatkan di posisi proxy, menggunakan API yang kompatibel dengan OpenAI, menerbitkan key terpisah untuk setiap klien, dan mencatat penggunaan setiap key. Gateway LiteLLM yang di-host sendiri biasanya menjadi solusi, dan menambahkan anggaran per key serta log permintaan di atas kontrol akses.

Aturan dari pertahanan 1 tetap berlaku. Ollama melakukan binding ke 127.0.0.1, gateway adalah satu-satunya proses yang berkomunikasi dengannya, dan gateway adalah satu-satunya service dengan listener publik. Gateway pada server yang port 11434-nya masih terbuka untuk publik hanya menjadi hiasan, karena klien dapat langsung melewatinya.

Perangkap firewall: port container yang dipublikasikan melewati UFW

Inilah alasan instance yang terekspos dapat ada pada server yang pemiliknya telah mengonfigurasi firewall dengan benar.

UFW (uncomplicated firewall) menulis aturannya ke dalam chain INPUT pada tabel kernel filter, sedangkan INPUT menangani paket yang ditujukan langsung ke host. Flag -p milik Docker menulis aturan destination NAT (network address translation) ke dalam chain PREROUTING pada tabel nat. Kernel mengevaluasi aturan ini sebelum menentukan tujuan paket. Saat keputusan routing dibuat, tujuan paket sudah diubah ke alamat container. Karena itu, paket diteruskan, bukan dikirim secara lokal, dan melewati FORWARD, bukan INPUT. Aturan INPUT milik UFW tidak pernah diperiksa. Akibatnya, paket melewati firewall, bukan melalui firewall.

Itulah alasan urutan berikut membuat port 11434 terbuka ke Internet:

sudo ufw default deny incoming
sudo ufw enable
docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

Namun, sudo ufw status tetap melaporkan bahwa firewall aktif dengan kebijakan default deny. Kedua hasil tersebut benar pada saat yang sama. Inilah alasan orang mempercayai hasil yang keliru. Anda dapat melihat aturan yang menyebabkannya:

sudo iptables -t nat -L DOCKER -n

Perbaikannya adalah menambahkan satu alamat pada flag publish:

docker rm -f ollama
docker run -d -v ollama:/root/.ollama -p 127.0.0.1:11434:11434 --name ollama ollama/ollama

-p 11434:11434 adalah bentuk singkat dari -p 0.0.0.0:11434:11434. Penetapan 127.0.0.1 mengikat sisi host dari pemetaan ke loopback. Dengan demikian, SSH tunnel dan reverse proxy tetap dapat mengaksesnya, sedangkan Internet tidak dapat mengaksesnya. Membuat ulang container aman dilakukan karena model tersimpan di dalam volume bernama ollama, bukan di dalam container.

Pastikan kedua tampilan memberikan hasil yang sama:

docker port ollama
sudo ss -tlnp | grep 11434

docker port ollama seharusnya menampilkan 11434/tcp -> 127.0.0.1:11434. Jika menampilkan 0.0.0.0:11434, host masih terekspos. Setelah memahami mekanisme ini, Anda dapat menerapkannya pada setiap container yang dipublikasikan: alasan port yang dipublikasikan Docker melewati UFW membahas chain DOCKER-USER dan aturan yang tetap ada setelah Docker dijalankan ulang. Jika Anda masih menyusun kebijakan host itu sendiri, aturan UFW yang diperlukan VPS baru membahas dasar yang digunakan oleh konfigurasi ini.

Sebagai akun apa proses berjalan

Skrip instalasi Linux membuat akun khusus dan menjalankan service menggunakan akun tersebut:

useradd -r -s /bin/false -U -m -d /usr/share/ollama ollama

Unit di /etc/systemd/system/ollama.service kemudian menetapkan User=ollama dan Group=ollama. Jangan ubah bagian itu. Perintah ollama serve yang dijalankan secara manual dari terminal akan berjalan sebagai pengguna yang Anda gunakan untuk login. Jika pengguna tersebut adalah root, API tanpa autentikasi dapat menulis file sebagai root. Periksa akun yang digunakan:

ps -o user= -C ollama

Hasilnya harus ollama. Hasil lain berarti proses yang dijalankan secara manual berjalan bersamaan dengan unit atau menggantikannya. Prinsip yang sama berlaku untuk setiap daemon yang Anda tambahkan nanti, dan menjalankan service sebagai pengguna dengan hak akses minimum menerapkannya dengan benar.

Cara memeriksa apakah endpoint API Ollama aman

Apa pun pilihan Anda, satu pengujian dapat memastikannya. Pengujian ini harus dijalankan dari mesin lain:

curl -m 5 http://YOUR_SERVER_IP:11434/api/version
curl -m 5 http://YOUR_SERVER_IP:11434/api/tags

Kedua permintaan tersebut harus mengalami timeout atau ditolak. Jika Anda membuat proxy, dua path yang sama pada hostname proxy harus mengembalikan 401 tanpa kredensial dan JSON yang valid dengan kredensial.

Kemudian baca access log satu kali. Log tersebut menunjukkan apakah ada pihak yang menemukan port saat port itu masih terbuka:

journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1

Ollama menulis satu baris untuk setiap permintaan dan menyertakan alamat klien:

[GIN] 2026/08/12 - 14:01:10 | 200 | 103.965898ms | 127.0.0.1 | POST "/api/generate"

Setiap baris harus menampilkan 127.0.0.1 satu kali setelah Ollama terikat ke loopback, karena hanya alamat tersebut yang dapat menjadi asal koneksi. Alamat publik pada kolom tersebut menunjukkan permintaan dari luar, dan timestamp menunjukkan waktunya. Tidak adanya output dari perintah tersebut adalah hasil yang diharapkan. Jika bagian model ini masih baru bagi Anda, menjalankan Ollama pada VPS membahas instalasi, penentuan ukuran model, dan batas memori yang menentukan model yang benar-benar dapat dimuat.

FAQ

Apakah Ollama memiliki kunci API atau kata sandi?

Tidak. Server yang Anda jalankan tidak memiliki autentikasi dalam bentuk apa pun, dan dokumentasi resmi menyatakan bahwa autentikasi tidak diperlukan untuk mengakses API. Kedua hal yang disebut sebagai "kunci API Ollama" justru digunakan untuk tujuan lain. Pasangan Ed25519 di /usr/share/ollama/.ollama/ membuktikan identitas mesin Anda kepada ollama.com agar Anda dapat mengirim model dan mengambil model privat. OLLAMA_API_KEY adalah kredensial yang dikirim klien Anda ke API ter-host di https://ollama.com/api. ollama serve milik Anda sendiri tidak membaca keduanya, sehingga kontrol akses harus diterapkan melalui jaringan atau proxy di depannya.

Apakah OLLAMA_HOST=0.0.0.0 aman jika saya menggunakan firewall?

Hanya selama tidak ada komponen lain yang menulis aturan firewall pada mesin tersebut. 0.0.0.0 berarti listener benar-benar ada pada antarmuka publik, dan Anda sepenuhnya mengandalkan firewall agar listener itu tidak dapat dijangkau. Kepercayaan tersebut tidak berlaku lagi saat Docker mempublikasikan port, karena aturan DNAT yang ditambahkan Docker ke tabel nat dievaluasi sebelum paket mencapai chain INPUT tempat UFW bekerja. Akibatnya, paket diteruskan dan tidak pernah dilihat oleh UFW. Binding ke 127.0.0.1 atau ke alamat tunnel privat menghapus listener dari antarmuka publik, sehingga kesalahan konfigurasi firewall tidak lagi memiliki listener yang dapat diekspos.

Bagaimana cara memeriksa apakah port Ollama saya terbuka ke Internet?

Jalankan sudo ss -tlnp | grep 11434 pada server dan curl -m 5 http://YOUR_SERVER_IP:11434/api/version dari mesin lain. Jika ss menampilkan 127.0.0.1:11434 dan curl dari jarak jauh mengalami timeout, itulah hasil yang Anda harapkan. Jika ss menampilkan 0.0.0.0:11434 atau *:11434, sementara curl dari jarak jauh mengembalikan JSON, berarti seluruh API dapat dijangkau. Jangan pernah menguji dengan curl pada server itu sendiri, karena loopback akan merespons apa pun alamat bind yang digunakan.

Apakah saya dapat memindahkan port dari 11434 ke port acak?

Tidak, dan alasannya perlu dijelaskan. Port yang berbeda tidak menghambat apa pun selain pemindaian terhadap satu port tertentu. Pemindai memeriksa seluruh rentang port, dan satu permintaan ke /api/tags dapat mengidentifikasi service tersebut, apa pun port yang digunakan. Memindahkan port juga merusak default setiap klien dan membuat konfigurasi Anda sendiri lebih sulit dipahami di kemudian hari. Gunakan bind ke loopback, karena cara ini menghapus listener, bukan hanya memindahkannya.

Seseorang mengakses Ollama saya yang terbuka. Apa yang harus saya periksa?

Bind ke 127.0.0.1 dan restart service terlebih dahulu agar akses tersebut berhenti sebelum Anda memulai penyelidikan. Kemudian jalankan journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1 untuk melihat alamat eksternal mana yang memanggil endpoint tertentu dan kapan pemanggilan itu terjadi. Bandingkan ollama list dengan model yang memang Anda inginkan, karena /api/pull tidak menggunakan autentikasi dan model yang tidak Anda ambil merupakan penggunaan ruang disk sekaligus bukti akses. Periksa ruang kosong dengan df -h. Ollama tidak mencatat teks prompt pada tingkat log default, sehingga Anda memiliki catatan tentang siapa yang membuat permintaan dan model yang digunakan, bukan tentang teks yang dihasilkan.

#ollama#security#api#firewall#reverse-proxy