Oleh Matt Connor
Cara Lindungi API Ollama Tanpa Kata Laluan
Pelayan Ollama tidak mempunyai pengesahan pada port 11434 secara lalai. Sesiapa sahaja boleh memuat turun atau memadam model anda. Ikuti tiga langkah mudah untuk mengunci akses.
API Ollama tidak mempunyai kata laluan
API Ollama tidak mempunyai pengesahan. Tiada pengguna, tiada kata laluan, tiada semakan kunci dan tiada senarai kebenaran (allowlist) di mana-mana dalam pelayan yang anda jalankan. Sesiapa sahaja yang boleh membuka sambungan TCP ke port 11434 boleh menyenaraikan model anda, menjalankannya, memuat turun model baharu dan memadamkan model yang anda miliki.
Dokumentasi rasmi menyatakan perkara ini dengan jelas: "Tiada pengesahan diperlukan apabila mengakses API Ollama secara setempat melalui http://localhost:11434." Perkataan setempat (locally) membawa keseluruhan model keselamatan tersebut. Ollama mengikat (bind) kepada 127.0.0.1 secara lalai, jadi pada komputer riba, antara muka loopback bertindak sebagai kawalan akses. Alihkan pendengar (listener) tersebut ke alamat awam dan kawalan akses itu hilang, kerana tiada apa-apa yang menggantikannya.
Itulah sebabnya perkara ini penting pada VPS (virtual private server). Tetapan lalai adalah selamat. Perubahan pertama yang dilakukan oleh kebanyakan orang, iaitu membuka pendengar supaya mesin kedua boleh menggunakan model tersebut, merupakan perubahan yang menghapuskan setiap perlindungan serta-merta.
Pendedahan yang berlaku apabila port 11434 dibuka
Setiap titik akhir (endpoint). Tiada mod baca sahaja dan tiada port pentadbir yang berasingan. Ini adalah permintaan sebenar yang ditujukan ke alamat pelayan dan bukannya 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"}'Dari sudut pandangan pengendali, empat perkara akan berlaku:
- CPU atau GPU anda menjalankan inferens untuk pihak lain. Pada pelan dengan had penggunaan CPU yang adil, beban berterusan bermakna kuota anda dihabiskan oleh orang asing, dan mengawal kos beban kerja AI pada VPS menjadi jauh lebih sukar apabila anda bukan satu-satunya pemanggil.
/api/pullmenulis ke cakera anda. Model bersaiz antara dua hingga empat puluh gigabait setiap satu. Gelung muat turun (pull) akan memenuhi storan, dan cakera yang penuh akan menyebabkan setiap servis lain pada mesin tersebut terhenti, bukan sahaja Ollama.- Permintaan sampai ke dalam proses anda dan direkodkan. Pada tahap log lalai, Ollama hanya merekodkan metadata, jadi anda mendapat titik akhir, status, kependaman (latency) dan alamat klien, bukan teks gesaan (prompt). Walau bagaimanapun, ia tetap menjadi rekod tentang siapa yang menggunakan mesin anda dan untuk tujuan apa, yang tersimpan dalam jurnal anda, dan anda tidak memilih untuk mengumpulnya.
/api/deletememadamkan model. Untuk mendapatkannya semula bermakna anda perlu memuat turunnya sekali lagi menggunakan lebar jalur anda sendiri.
Tiada satu pun daripada ini memerlukan eksploitasi. Ia adalah API yang didokumentasikan dan berfungsi tepat seperti yang direka bentuk.
Kunci Ed25519 bukanlah kawalan akses
Cari "Ollama API key" dan anda akan menemui dua perkara yang berbeza. Tiada satu pun daripadanya merupakan kata laluan untuk pelayan anda, dan membezakan kedua-duanya akan meleraikan kebanyakan kekeliruan.
Yang pertama ialah pasangan kunci identiti. Ollama menjana pasangan kunci Ed25519 pada permulaan pertama. Pada Linux, skrip pemasangan mencipta pengguna sistem bernama ollama dengan direktori utama di /usr/share/ollama, jadi pasangan kunci tersebut berada di sini:
/usr/share/ollama/.ollama/id_ed25519
/usr/share/ollama/.ollama/id_ed25519.pubKunci itu menghala ke luar. ollama signin mendaftarkan bahagian awam dengan akaun ollama.com anda, dan ia merupakan perkara yang membenarkan anda menolak (push) model ke pendaftaran atau menarik (pull) model peribadi. Ia membuktikan mesin anda kepada ollama.com. Ia tidak meminta apa-apa daripada klien yang bersambung ke mesin anda. Memadamnya, menukarnya atau tidak pernah menciptanya tidak mengubah apa-apa tentang siapa yang boleh memanggil API anda.
Yang kedua ialah OLLAMA_API_KEY. Pemboleh ubah itu menyimpan kunci yang anda cipta di https://ollama.com/settings/keys, dan klien anda menghantarnya sebagai Authorization: Bearer $OLLAMA_API_KEY apabila memanggil API yang dihoskan di https://ollama.com/api. Ia merupakan kelayakan untuk perkhidmatan mereka, yang digunakan oleh anda sebagai klien. ollama serve anda sendiri tidak pernah membacanya. Menetapkan OLLAMA_API_KEY pada VPS anda tidak meletakkan kata laluan pada VPS anda.
Oleh itu, tiada tetapan untuk dihidupkan. Tiga pertahanan di bawah semuanya berfungsi dengan cara yang sama: pastikan port tidak boleh dicapai, dan letakkan sesuatu di hadapannya yang melakukan pemeriksaan.
Semak port yang sedang mendengar pada pelayan anda sekarang
sudo ss -tlnp | grep 11434Hasil yang selamat akan memaparkan alamat loopback:
LISTEN 0 4096 127.0.0.1:11434 0.0.0.0:* users:(("ollama",pid=812,fd=3))Hasil yang terdedah akan memaparkan setiap antara muka (interface):
LISTEN 0 4096 0.0.0.0:11434 0.0.0.0:* users:(("ollama",pid=812,fd=3))0.0.0.0 bermaksud semua alamat IPv4 pada mesin tersebut, termasuk alamat awam. *:11434 dan [::]:11434 membawa maksud yang sama dengan menyertakan IPv6.
Sekarang, sahkan dari luar. Jalankan arahan ini pada komputer riba anda, bukan pada pelayan:
curl -m 5 http://YOUR_SERVER_IP:11434/api/versioncurl: (28) Connection timed out after 5001 milliseconds ialah jawapan yang anda mahukan, begitu juga dengan curl: (7) Failed to connect ... Connection refused. Objek JSON yang membawa medan version bermaksud keseluruhan API boleh dicapai oleh sesiapa sahaja yang memintanya. Ujian menggunakan curl pada pelayan itu sendiri tidak membuktikan apa-apa, kerana loopback sentiasa memberi respons.
Pendedahan biasanya berlaku melalui salah satu daripada dua cara. Cara pertama ialah suntingan sengaja, kerana seseorang memerlukan mesin kedua untuk mencapai model tersebut:
sudo systemctl edit ollama.service[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"Satu baris itu sahaja merupakan punca keseluruhan pendedahan. Cara kedua ialah Docker, dan ia tidak meminta anda menyunting apa-apa pun. Perkara itu mempunyai bahagiannya sendiri di bawah.
Pertahanan 1: kekalkan pada localhost dan gunakan tunnel
Gunakan kaedah ini sebagai langkah pertama. Ia tidak memerlukan perisian baharu dan tidak mencipta sebarang kelayakan yang boleh bocor. Port tersebut tidak wujud pada antaramuka awam, jadi pengimbasan tidak akan menemuinya.
Tetapkan alamat bind secara eksplisit dan jangan bergantung pada tetapan lalai:
sudo systemctl edit ollama.service[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"Tindakan itu menulis /etc/systemd/system/ollama.service.d/override.conf. Gunakan tetapan tersebut dan semak:
sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ss -tlnp | grep 11434ss kini sepatutnya menunjukkan 127.0.0.1:11434. Jika ia masih menunjukkan 0.0.0.0, fail drop-in kedua sedang mengatasi tetapan anda. Jalankan systemctl cat ollama.service untuk menyenaraikan unit tersebut beserta setiap fail drop-in dan laluannya, kemudian padamkan fail yang lama.
Untuk menggunakan model daripada komputer riba anda, forward port tersebut 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 komputer riba anda dan menghantar sebarang trafik yang tiba di situ ke 127.0.0.1:11434 seperti yang dilihat dari pelayan. -N memberitahu SSH supaya tidak menjalankan arahan jauh, jadi proses tersebut hanya mengekalkan tunnel agar sentiasa terbuka. Semasa ia berjalan, arahan ini berfungsi pada komputer riba anda:
curl -s http://localhost:11434/api/tagsDua kegagalan yang mungkin anda temui. bind [127.0.0.1]:11434: Address already in use bermaksud komputer riba anda sedang menjalankan Ollama sendiri pada port tersebut, jadi pilih port tempatan yang berbeza dengan -L 11500:127.0.0.1:11434 dan halakan klien anda ke 11500. Balasan kosong melalui tunnel yang berjaya disambungkan bermaksud SSH berfungsi tetapi Ollama tidak mendengar pada sisi pelayan, jadi semak ss di sana sebelum anda mengubah arahan SSH.
Untuk beberapa mesin klien, rangkaian peribadi adalah lebih baik daripada satu tunnel bagi setiap pengguna. Letakkan mesin-mesin tersebut dalam WireGuard atau Tailscale, kemudian bind Ollama ke alamatnya pada rangkaian tersebut dan bukannya ke 0.0.0.0:
[Service]
Environment="OLLAMA_HOST=10.8.0.1:11434"Port tersebut kemudiannya hanya wujud pada antaramuka yang memerlukan kunci untuk diakses. Ini juga kekal selamat sekiranya berlaku kesilapan pada firewall, kerana peraturan yang secara tidak sengaja membenarkan akses awam tetap tidak dapat mendedahkan listener yang tidak dipegang oleh antaramuka awam.
Pertahanan 2: reverse proxy yang memeriksa bearer token
Apabila sesuatu di internet awam perlu memanggil model, kekalkan Ollama pada loopback dan letakkan proxy di hadapannya. Proxy tersebut menamatkan TLS (transport layer security) dan menolak permintaan tanpa header yang betul. Ollama masih hanya menerima sambungan daripada 127.0.0.1, jadi proxy adalah satu-satunya laluan masuk.
Jana token sebenar terlebih dahulu. Jangan cipta token secara manual:
openssl rand -base64 36Tapak nginx yang memeriksanya:
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 situ melakukan kerja sebenar, dan setiap satunya menghalang kegagalan yang mungkin anda hadapi.
if di dalam blok location biasanya merupakan idea yang buruk dalam nginx, tetapi badan yang tepat return adalah salah satu daripada dua bentuk yang berkelakuan secara boleh jangka, jadi penggunaan ini adalah selamat.
location = /api/pull ialah padanan tepat, dan nginx meletakkan padanan tepat lebih tinggi daripada awalan location /, jadi ketiga-tiga endpoint tersebut ditolak sebelum token pun dipertimbangkan. Token yang sah kemudiannya memberikan akses kepada inferens, bukan keupayaan untuk memenuhi cakera anda.
proxy_set_header Host 127.0.0.1:11434; penting kerana Ollama memeriksa header Host dan Origin yang masuk. Menghantar hostname awam proxy secara terus boleh menghasilkan 403 Forbidden yang datang daripada Ollama dan bukannya daripada nginx, yang mengelirukan untuk dinyahpepijat. OLLAMA_ORIGINS adalah tuil yang satu lagi, untuk klien pelayar yang memerlukan origin tertentu dibenarkan.
proxy_buffering off; penting kerana Ollama menstrim responsnya token demi token. Dengan buffering diaktifkan, nginx menahan strim tersebut dan menghantarnya sebagai satu bahagian pada penghujung, jadi klien anda kelihatan beku sepanjang tempoh penjanaan.
proxy_read_timeout 600s; penting kerana nginx menetapkan nilai lalai kepada 60 saat. Penjanaan yang lama pada CPU mudah melepasi tempoh tersebut, klien mendapat 504 Gateway Time-out, dan /var/log/nginx/error.log merekodkan upstream timed out (110: Connection timed out) while reading response header from upstream. Permintaan tersebut sebenarnya masih berfungsi. nginx yang berputus asa terhadapnya.
Muat semula dan uji kedua-dua laluan:
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/tagsYang pertama sepatutnya mencetak 401. Yang kedua sepatutnya mencetak senarai model anda. Jika yang pertama juga mengembalikan senarai model, blok map berada dalam skop yang salah. Ia sepatutnya berada pada tahap http, jadi letakkannya dalam fail di bawah /etc/nginx/conf.d/ atau di atas blok server, jangan sekali-kali di dalam server.
Caddy melakukan tugas yang sama dengan pengesahan asas dalam empat baris, yang lebih sesuai untuk klien pelayar berbanding 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 dijangkakan. Satu perangkap penamaan: direktif tersebut adalah basicauth sebelum Caddy v2.8 dan kini menjadi basic_auth, jadi konfigurasi yang disalin daripada panduan lama akan gagal dimuatkan dan Caddy akan menamakan direktif yang tidak dikenalinya.
Tidak kira proxy mana yang anda pilih, ini adalah satu rahsia kongsi untuk semua orang. Setiap klien yang memegangnya mempunyai akses yang sama, dan membatalkannya bermakna menyunting konfigurasi dan mengemas kini setiap pemanggil pada masa yang sama.
Pertahanan 3: gerbang yang mengeluarkan kunci bagi setiap klien
Apabila lebih daripada seorang pengguna atau aplikasi memanggil model tersebut, token yang dikongsi akan menjadi tidak mencukupi. Anda tidak dapat mengenal pasti klien mana yang menyebabkan beban tersebut, dan anda tidak boleh menyekat salah satu daripadanya tanpa menjejaskan kesemuanya. Sebuah gerbang diletakkan di lokasi proksi sebelum ini, menggunakan API yang serasi dengan OpenAI, mengeluarkan kunci berasingan bagi setiap klien, dan merekodkan penggunaan setiap kunci. Gerbang LiteLLM yang dihoskan sendiri merupakan penyelesaian lazim, dan ia menambah belanjawan bagi setiap kunci serta log permintaan di samping kawalan akses.
Peraturan daripada pertahanan 1 tidak berubah. Ollama terikat pada 127.0.0.1, gerbang tersebut merupakan satu-satunya proses yang berhubung dengannya, dan gerbang tersebut merupakan satu-satunya servis yang mempunyai pendengar awam. Gerbang pada mesin yang port 11434 masih terbuka kepada umum hanyalah hiasan, kerana pemanggil boleh melangkauinya dengan mudah.
Perangkap firewall: port kontena yang diterbitkan memintas UFW
Inilah sebabnya wujud instans yang terdedah pada pelayan yang pemiliknya telah mengkonfigurasi firewall dengan betul.
UFW (uncomplicated firewall) menulis peraturannya ke dalam chain INPUT pada jadual filter kernel, dan INPUT mengendalikan paket yang ditujukan kepada hos itu sendiri. Flag -p Docker menulis peraturan destination NAT (network address translation) ke dalam chain PREROUTING pada jadual nat, yang dinilai oleh kernel sebelum ia memutuskan ke mana paket tersebut akan pergi. Apabila keputusan penghalaan dibuat, destinasi telah pun ditulis semula kepada alamat kontena, jadi paket tersebut diforward dan bukannya dihantar secara setempat, lalu ia merentasi FORWARD dan bukannya INPUT. Peraturan INPUT UFW tidak pernah dirujuk, jadi paket tersebut memintas firewall dan bukannya melaluinya.
Itulah sebabnya urutan ini membiarkan port 11434 terbuka kepada internet:
sudo ufw default deny incoming
sudo ufw enable
docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollamadan sudo ufw status masih melaporkan firewall aktif dengan polisi default deny. Kedua-dua bacaan adalah betul pada masa yang sama, dan itulah sebabnya orang ramai mempercayai bacaan yang salah. Anda boleh melihat peraturan yang menyebabkannya:
sudo iptables -t nat -L DOCKER -nPenyelesaiannya adalah dengan meletakkan satu alamat dalam 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 ialah singkatan untuk -p 0.0.0.0:11434:11434. Menamakan 127.0.0.1 mengikat bahagian hos bagi pemetaan tersebut kepada loopback, supaya tunnel SSH dan reverse proxy anda masih boleh mencapainya manakala internet tidak boleh. Mencipta semula kontena adalah selamat di sini kerana model disimpan dalam volume ollama yang dinamakan, bukan di dalam kontena.
Sahkan bahawa kedua-dua pandangan adalah selaras:
docker port ollama
sudo ss -tlnp | grep 11434docker port ollama sepatutnya memaparkan 11434/tcp -> 127.0.0.1:11434. Jika ia memaparkan 0.0.0.0:11434, anda masih terdedah. Fahami mekanisme ini sekali dan ia terpakai untuk setiap kontena yang anda terbitkan: mengapa port yang diterbitkan Docker memintas UFW merangkumi chain DOCKER-USER dan peraturan yang kekal selepas Docker dimulakan semula. Jika anda masih membina polisi hos itu sendiri, peraturan UFW yang diperlukan oleh VPS baharu merangkumi asas bagi perkara ini.
Siapakah pengguna yang menjalankan proses tersebut
Skrip pemasangan Linux mencipta akaun khusus dan menjalankan servis di bawah akaun tersebut:
useradd -r -s /bin/false -U -m -d /usr/share/ollama ollamaUnit pada /etc/systemd/system/ollama.service kemudian menetapkan User=ollama dan Group=ollama. Jangan ubah tetapan ini. ollama serve pantas yang dimulakan secara manual dalam terminal akan berjalan sebagai pengguna yang log masuk, dan jika pengguna tersebut ialah root, maka API yang tidak disahkan akan menulis fail sebagai root. Semak yang mana satu sedang berjalan:
ps -o user= -C ollamaJawapannya sepatutnya ollama. Sebarang jawapan lain bermakna proses yang dimulakan secara manual sedang berjalan bersama-sama atau menggantikan unit tersebut. Pemikiran yang sama terpakai untuk setiap daemon yang anda tambah kemudian, dan menjalankan servis sebagai pengguna dengan keistimewaan terendah membincangkan perkara ini dengan lebih terperinci.
Cara menyemak sama ada endpoint API Ollama selamat
Walau apa pun pilihan anda, satu ujian akan menentukan statusnya, dan ujian ini mesti dijalankan dari mesin lain:
curl -m 5 http://YOUR_SERVER_IP:11434/api/version
curl -m 5 http://YOUR_SERVER_IP:11434/api/tagsKedua-duanya sepatutnya tamat masa (time out) atau ditolak. Jika anda membina proksi, dua path yang sama pada hostname proksi sepatutnya mengembalikan 401 tanpa kelayakan, dan JSON sebenar jika kelayakan disertakan.
Kemudian, baca log capaian sekali, kerana ia memberitahu anda sama ada sesiapa telah menemui port tersebut semasa ia terbuka:
journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1Ollama menulis satu baris bagi 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 sepatutnya menunjukkan 127.0.0.1 sebaik sahaja Ollama diikat (bound) pada loopback, kerana itu adalah satu-satunya alamat yang boleh menerima sambungan. Alamat awam dalam lajur tersebut bermakna permintaan datang dari luar, dan cap masa memberitahu anda bila ia berlaku. Tiada output langsung daripada arahan tersebut adalah hasil yang anda mahukan. Jika bahagian model ini baharu bagi anda, menjalankan Ollama pada VPS merangkumi pemasangan, saiz model dan had memori yang menentukan apa yang sebenarnya akan dimuatkan.
FAQ
Adakah Ollama mempunyai API key atau kata laluan?
Tidak. Pelayan yang anda jalankan tidak mempunyai sebarang bentuk pengesahan, dan dokumentasi rasmi menyatakan bahawa tiada pengesahan diperlukan untuk mencapai API tersebut. Kedua-dua perkara yang dipanggil "Ollama API key" berfungsi sebaliknya. Pasangan Ed25519 dalam /usr/share/ollama/.ollama/ membuktikan mesin anda kepada ollama.com supaya anda boleh menolak (push) model dan menarik (pull) model peribadi. OLLAMA_API_KEY ialah kelayakan yang dihantar oleh klien anda kepada API yang dihoskan di https://ollama.com/api. ollama serve anda sendiri tidak membaca kedua-duanya, jadi kawalan akses perlu datang daripada rangkaian atau daripada proksi di hadapan.
Adakah OLLAMA_HOST=0.0.0.0 selamat jika saya mempunyai firewall?
Hanya selagi tiada perkara lain yang menulis peraturan firewall pada kotak tersebut. 0.0.0.0 bermakna pendengar (listener) benar-benar wujud pada antara muka awam, dan anda hanya mempercayai firewall untuk memastikan ia tidak boleh dicapai. Kepercayaan itu terputus sebaik sahaja Docker menerbitkan port, kerana peraturan DNAT yang ditambah oleh Docker ke dalam jadual nat dinilai sebelum paket sampai ke rantaian INPUT tempat UFW berada, jadi paket tersebut dimajukan dan UFW tidak pernah melihatnya. Mengikat (bind) kepada 127.0.0.1 atau kepada alamat terowong peribadi akan mengalih keluar pendengar daripada antara muka awam, jadi kesilapan firewall tidak akan mendedahkan apa-apa.
Bagaimanakah cara saya menyemak sama ada port Ollama saya terbuka kepada internet?
Jalankan sudo ss -tlnp | grep 11434 pada pelayan, dan curl -m 5 http://YOUR_SERVER_IP:11434/api/version daripada mesin yang berbeza. ss yang menunjukkan 127.0.0.1:11434 dan curl jauh yang tamat tempoh (timeout) adalah pasangan jawapan yang anda mahukan. ss yang menunjukkan 0.0.0.0:11434 atau *:11434 sementara curl jauh mengembalikan JSON bermakna API penuh boleh dicapai. Jangan sekali-kali menguji dengan curl pada pelayan itu sendiri, kerana loopback akan menjawab walau apa pun alamat bind yang ditetapkan.
Bolehkah saya hanya menukar port daripada 11434 kepada sesuatu yang rawak?
Tidak, dan sebabnya perlu dinyatakan. Port yang berbeza tidak melambatkan apa-apa kecuali imbasan pada satu port tunggal. Pengimbas akan menyemak keseluruhan julat, dan satu permintaan kepada /api/tags akan mengenal pasti servis tersebut tidak kira pada port mana ia tiba. Menukar port juga merosakkan setiap tetapan lalai klien dan menjadikan persediaan anda sendiri lebih sukar untuk difahami kemudian hari. Ikat kepada loopback sebaliknya, yang akan mengalih keluar pendengar dan bukannya menempatkannya semula.
Seseorang telah mencapai Ollama saya yang terbuka. Apakah yang perlu saya semak?
Ikat ia kepada 127.0.0.1 dan mulakan semula servis terlebih dahulu, supaya pendedahan berhenti sebelum anda mula menyiasat. Kemudian jalankan journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1 untuk melihat alamat luar yang mana telah memanggil endpoint yang mana dan bila. Bandingkan ollama list dengan model yang sepatutnya anda miliki, memandangkan /api/pull tidak disahkan dan model yang anda tidak tarik (pull) adalah penggunaan cakera serta bukti. Semak ruang kosong dengan df -h. Ollama tidak merekodkan teks gesaan (prompt) pada tahap log lalai, jadi anda mempunyai rekod tentang siapa yang bertanya dan untuk model yang mana, bukan tentang apa yang dijana.