Moli self-host: Küçük VPS için headless browser

Küçük bir VPS üzerinde çalışabilen başsız (headless) tarayıcı

Moli, yapay zeka aracıları için tasarlanmış bir başsız tarayıcıdır ve headless Chrome'un sığmayacağı kadar küçük bir VPS üzerinde kendi kendine barındırılabilir (self-host). Chromium etrafına sarılmış bir sarmalayıcı değil, Rust ile yazılmış bir tarayıcı motorudur ve otomasyon kütüphanenizin halihazırda konuştuğu Chrome DevTools Protocol (CDP) ile yanıt verir. Tek bir binary dosyasını kurun, moli serve komutunu çalıştırın ve ardından Playwright'ı veya kendi aracı kodunuzu http://127.0.0.1:9222 adresine yönlendirin.

Herhangi bir kurulum yapmadan önce ödünleşimleri (trade-off) okuyun. Proje, kapsamını açıkça belirtmektedir: GUI tarayıcısı yoktur, GPU birleştiricisi (compositor) yoktur, Chrome ile pikseli pikseline uyumluluk yoktur ve yüksek doğrulukta Canvas veya medya oynatma desteği yoktur. Bunlara ihtiyaç duyan sayfalar başarısız olacaktır. Playwright altındaki gerçek Chrome yedek seçenek olarak kalmaya devam eder ve son bölüm, hangi sayfaların buna ihtiyaç duyduğuna nasıl karar vereceğinizi gösterir.

Aşağıdaki her komut, projenin README dosyasından ve yayınlanmış yetenek dosyalarından alınmış olup 20 Ekim 2026 tarihinde tekrar kontrol edilmiştir. Tablolardaki her sayı, bu sitenin ölçümü değil, projenin kendi motoru hakkında yayınladığı verilerdir ve her tablo başlığı bunu belirtmektedir. Eğer hala bir motor seçme aşamasındaysanız, VPS üzerinde aracı odaklı başsız tarayıcılar hakkındaki daha geniş kapsamlı inceleme alternatifleri ele almaktadır.

Headless Chrome neden bu kadar çok bellek kullanıyor?

Chrome, çok süreçli (multi-process) bir tarayıcıdır. Belgeleri site bazında gruplandırır ve masaüstü Linux üzerinde tam Site Isolation özelliği, siteler arası iframe'ler dahil olmak üzere her siteyi kendi oluşturucu (renderer) süreçlerinde tutar. Chrome, aynı siteye ait sayfaların bir oluşturucuyu paylaşmasına izin verebilir ancak birden fazla siteye erişen bir oturum yine de bu süreçlerden birkaçını çalıştırır ve her oluşturucu kendi V8 yığınını (heap) ve grafik arabelleklerini taşır. Bu tasarım, çöken bir sayfanın tüm pencereyi beraberinde götürmemesi gereken masaüstü ortamları için doğrudur. 2 GB RAM'e sahip bir VPS üzerinde bu, tek bir tarama adımının aslında çalıştırdığınız uygulamadan daha fazla bellek tüketebileceği anlamına gelir.

Proje, dört farklı motor kullanarak 192 karma genel URL'yi taradı ve sonuçları yayınladı.

[
  {
    "engine": "Moli",
    "useful_pages": 103,
    "median_rss_mib": 73
  },
  {
    "engine": "Chrome Headless",
    "useful_pages": 101,
    "median_rss_mib": 773
  },
  {
    "engine": "Lightpanda",
    "useful_pages": 85,
    "median_rss_mib": 40
  },
  {
    "engine": "Obscura",
    "useful_pages": 57,
    "median_rss_mib": 39
  }
]

Chrome Headless 101 adet faydalı sayfa döndürürken, Moli 103 adet döndürdü; yani bu örneklemde iki motor da web'in yaklaşık aynı kısmını okudu. Bellek kullanımı ise ayrıştıkları noktadır: Chrome için medyan RSS (resident set size, bir sürecin RAM'de fiilen tuttuğu bellek miktarı) 773 MiB iken, Moli için bu değer 73 MiB'dir. Bu eğilim, süreç mimarisinden kaynaklandığı için güvenilirdir. Kendi sayfalarınızdaki kesin oran, varsayımda bulunmamanız gereken bir konudur.

Sizi zorlayan değer medyan değil, zirve değerdir. 2 GB'lık bir sunucunun belleği tükendiğinde, çekirdek bir süreci seçer ve sonlandırır; bu kayıt da dmesg -T veya journalctl -k dosyasına düşer:

Out of memory: Killed process 4211 (chrome) total-vm:2318936kB, anon-rss:1418324kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:3540kB oom_score_adj:0

Aracınız bu satırı asla görmez. Bunun yerine, genellikle page.goto: Page crashed gibi bir Playwright hatası veya kapatılmış bir hedef olarak yanıt vermeyi durduran bir tarayıcı görür. Bu hatada bellekten bahsedilmez; bu nedenle, küçük bir sunucuda bir aracı rastgele başarısız olduğunda kontrol edilmesi gereken ilk şey OOM (out of memory) killer'dır. Zirve değerlere göre boyutlandırma yapmak, bir aracı VPS'i için RAM ve CPU seçimi ile aynı süreçtir.

Moli ikili dosyasını belirli bir sürüme sabitleyerek kurun

Proje, GitHub releases sayfasında bir kabuk yükleyici ve önceden derlenmiş tarball dosyaları yayınlamaktadır. 20 Ekim 2026 itibarıyla en yeni sürüm 17 Ekim 2026 tarihinde yayınlanan 1.1.18'dir ve sürümler hızla çıkmaktadır: 4 ile 17 Ekim arasında altı sürüm yayınlanmıştır. Proje, bu kılavuzun ilerleyen kısımlarında alıntılanan Lexbench skorunu 0.1.1 sürümünde ölçmüştür ve README dosyası diğer verilerin hangi sürüme ait olduğunu belirtmemektedir. Bunların tümünü, kuracağınız yapıya dair bir taahhüt değil, motorun genel yapısı hakkında bir fikir olarak değerlendirin.

Sürümü sabitleyin. Her zaman latest çözümlemesi yapan bir yükleyici, bir sonraki yeniden derlemede aracınızı farklı bir tarayıcı motoruna taşır; tarayıcı davranışındaki bir değişiklik, keşfetmek yerine planlamanız gereken türden bir değişikliktir.

Kabuk yükleyici hızlı bir yöntemdir ve çalıştırmadan önce okunması faydalıdır.

curl --proto '=https' --tlsv1.2 -fsSL \
  -o /tmp/moli-installer.sh \
  https://github.com/lexmount/moli/releases/download/v1.1.18/moli-installer.sh
less /tmp/moli-installer.sh
sh /tmp/moli-installer.sh

Komut dosyasını çalıştırmadan önce okuyun. Kısa bir dosyadır. uname -m üzerinden bir arşiv seçer ve ardından tek bir ikili dosyayı ~/.local/bin dizinine açar. x86_64 üzerinde moli-x86_64-unknown-linux-gnu.tar.gz dosyasını, Arm sunucuda ise aarch64 arşivini kullanır; böylece hem Arm hem de x86 VPS planları desteklenmiş olur. Farklı bir yere kurmak için MOLI_INSTALL_DIR değişkenini ayarlayın. Sürüm için neyi çözümlediğine dikkat edin: komut dosyasını çektiğiniz etiket değil, en yeni sürüm. Bu, ilk inceleme için uygundur ancak tekrarlanabilir olmasını istediğiniz bir yeniden derleme için yanlıştır.

Bu nedenle, kalıcı herhangi bir işlem için yükleyicinin yaptığını manuel olarak yapın ve arşiv adını kendiniz belirleyin. Bu yöntem aynı zamanda ikili dosyayı bir sistem servisinin erişebileceği bir yere koymanızı sağlar ve indirilen bir betiği doğrudan kabuğa yönlendirme (piping) zorunluluğunu ortadan kaldırır.

cd /tmp
curl --proto '=https' --tlsv1.2 -fsSLO \
  https://github.com/lexmount/moli/releases/download/v1.1.18/moli-x86_64-unknown-linux-gnu.tar.gz
mkdir -p moli-pkg
tar -xzf moli-x86_64-unknown-linux-gnu.tar.gz -C moli-pkg --strip-components=1
sudo install -m 0755 moli-pkg/moli /usr/local/bin/moli
moli --version

moli --version ile sabitlediğiniz sürümü yazdırmak, kontrolün tamamıdır. Yükleyiciden hemen sonra moli: command not found hatası alıyorsanız, kurulum dizini PATH yolunuzda (PATH) bulunmuyor demektir; yükleyici, eklemeniz gereken dizini belirten bir satır çıktısı verir.

moli fetch ile tek seferlik veri çıkarma

Bir agent'a verilen görevlerin çoğu, "bu URL'yi yükle ve ne yazdığını söyle" şeklindedir. Bunun için sunucu gerekmez. moli fetch motoru başlatır, tek bir sayfa yükler, tek bir artifact'i standard output'a yazar ve çıkar. Böylece çağrılar arasında bellekte veri tutulmaz.

moli fetch --dump markdown --wait-until networkidle https://example.com
moli fetch --dump semantic_tree_text --wait-selector "main" https://example.com
moli fetch --dump json --wait-until networkidle https://example.com > page.json

İlk komut, # Example Domain ile başlayan sayfayı Markdown olarak yazdırır. Markdown, markup'ı kaldırıp metni koruduğu için bir modele aktarılabilecek en düşük maliyetli biçimdir. semantic_tree_text rolleri ve yapıyı korur. Bu seçenek, bağlantıların metin kadar önemli olduğu, navigasyon ağırlıklı sayfalarda tercih edilmelidir. --dump json HTTP durumunu ve istek izini içerir. Bir fetch işlemi boş döndüğünde ve nedenini öğrenmek gerektiğinde bu seçenek kullanılmalıdır.

Bekleme stratejisi, içerik mi yoksa boş bir kabuk mu alınacağını belirler. --wait-until networkidle ağ trafiği durduğunda döner. --wait-until domstable DOM değişmeyi bıraktığında döner. Arka planda sürekli polling yapan ve bu nedenle ağ trafiğinin hiç durmadığı sayfalarda daha uygun seçenek budur. --wait-selector belirtilen tek bir selector için bekler. Fetch edilen sayfa hakkında bilgi sahibi olan tek strateji budur. Bu nedenle hedef biliniyorsa en güvenilir seçenektir.

Screenshot ve PDF için gerçek layout gerekir. Layout varsayılan olarak kapalıdır:

moli fetch --layout --dump screenshot https://example.com > page.png
moli fetch --layout --dump screenshot_full https://example.com > full-page.png
moli fetch --layout --dump pdf https://example.com > page.pdf

README'de varsayılan layout policy LayoutPolicy::Mock olarak belirtilir: geometry taklit edilir ve hiçbir şey render edilmez. Bunun nedeni, layout ve paint işlemlerinin browser kaynak tüketiminin pahalı bölümünü oluşturmasıdır. Yukarıdaki bellek değerlerinin bu şekilde görünmesinin nedeni de budur. Bu durum, boş bir PNG dosyasının genellikle bozuk bir sayfadan değil, eksik --layout flag'inden kaynaklandığı anlamına gelir.

Agent'ın sizin seçtiğiniz URL'ler yerine bulduğu URL'ler için --block-private-networks eklenmelidir. Bir sayfada okuduğu bağlantıları takip eden agent, cloud instance kimlik bilgileri için http://169.254.169.254/ adresine veya web'e açılması hiç amaçlanmamış bir localhost database portuna yönlendirilebilir. Bu flag, private address space içine yapılan navigation işlemlerini reddeder. --block-cidrs ise kapsamı daha da daraltır. İş tek bir sayfayı okumak yerine crawling yapıyorsa bu pipeline'ın yapısı self-hosted Firecrawl alternatifleri bölümünde ele alınır. Bundan önceki adım olan URL'leri bulma konusu ise agent'lar için SearXNG destekli search skill bölümünde ele alınır.

Moli'yi CDP üzerinden bir ajana bağlama

Birden fazla adımda gezinen ve tıklayan bir ajan için bunun yerine sunucuyu çalıştırın.

moli serve --host 127.0.0.1 --port 9222

127.0.0.1 ve 9222 numaralı port varsayılandır; bu nedenle yalnızca moli serve kullanıldığında da bind işlemi sadece loopback adresine yapılır. Yine de kalıcı yapılandırmalarda ikisini de açıkça yazın. Böylece service dosyasını daha sonra okuyacak kişinin varsayılan değeri hatırlaması gerekmez.

Bir istemciyi bağlamadan önce sunucuyu kontrol edin:

curl -s http://127.0.0.1:9222/json/version

Çalışan bir sunucu, webSocketDebuggerUrl alanını içeren bir JSON nesnesi döndürür. CDP istemcisi bu URL'ye bağlanır. curl: (7) Failed to connect to 127.0.0.1 port 9222: Connection refused hiçbir sürecin dinlemediğini gösterir. Bu durumda sunucuyu başlattığınız terminali kontrol edin veya servis olarak çalışıyorsa journalctl -u moli -n 50 komutunu kullanın. /json/list açık hedefleri, /json/protocol ise bu derlemenin uyguladığı alanları listeler. Böylece kullandığınız bir CDP yönteminin burada mevcut olup olmadığını öğrenebilirsiniz.

Playwright, kendi tarayıcısını başlatmak yerine bu uç noktaya bağlanır:

import { chromium } from "playwright";

const browser = await chromium.connectOverCDP("http://127.0.0.1:9222");
const context = browser.contexts()[0];
const page = context.pages()[0] ?? await context.newPage();

await page.goto("https://example.com");
console.log(await page.locator("body").innerText());

await browser.close();

Önemli olan satır connectOverCDP satırıdır; chromium.launch() değildir. Burada alt süreç olarak çalışan bir Chromium süreci yoktur. Bu nedenle executablePath ve --no-sandbox gibi yaygın container flag'lerinin etkileyebileceği bir süreç bulunmaz. Proxy, cookie ve user-agent ayarları da aynı nedenle Moli sunucusuna kendi flag'leri olarak verilir. CDP'nin tamamı yerine desteklenen CDP kapsamını bekleyin. Açıkça bildirilen bir desteklenmeyen yöntem hatası, kodunuzdaki bir hatayı değil, engine sınırını gösterir.

İki sunucu flag'i, ajanın neler yapabileceğini belirler. --layout gerçek geometriyi etkinleştirir. Koordinatla tıklama ve screenshot işlemleri için bu gerekir. --resource isteğe bağlı image, font ve media kaynaklarını alır. Bu işlem her sayfa yüklemesinde bandwidth ve memory tüketir. Bu nedenle bir sayfanın ihtiyaç duyduğu kanıtlanana kadar kapalı bırakın. --profile-dir cookie ve storage verilerini çalıştırmalar arasında kalıcı hale getirir. Bu olmadan her çalıştırma geçicidir.

[
  {
    "engine": "Moli",
    "cdp_ready_ms": 34.85,
    "peak_pss_mib": 102.46,
    "processes": 1
  },
  {
    "engine": "Chromium",
    "cdp_ready_ms": 169.37,
    "peak_pss_mib": 348.82,
    "processes": 11
  }
]

Projenin örnek agent workload'unda Moli, 34.85 ms içinde CDP bağlantısını kabul etti. Chromium için bu süre 169.37 ms idi. En yüksek PSS değeri, yani paylaşılan sayfaların bunları paylaşan süreçler arasında bölüştürülerek hesaba katıldığı proportional set size değeri, 102.46 MiB oldu. Chromium'da bu değer 348.82 MiB idi. Yapısal fark son sütundadır: 1 process yerine 11 process. Tek process, systemd tarafından denetlenecek tek bir bileşen ve sınırlandırılacak tek bir cgroup anlamına gelir. Bu nedenle sonraki bölüm kısa olur.

Loopback üzerinde moli serve uygulamasını systemd servisi olarak çalıştırma

Bir agent kendisini bekleyen bir tarayıcıya ihtiyaç duyduğunda sunucuyu servis olarak çalıştırın. Böyle bir ihtiyaç yoksa URL başına moli fetch kullanmaya devam edin; çünkü boşta bekleyen bir sunucu da belleği kullanmaya devam eder.

9222 numaralı portu public bir arayüzde dinlemeye açmayın. CDP hiçbir türde kimlik doğrulama adımı içermez. Bu porta erişebilen herkes tarayıcıyı yönetebilir ve tarayıcının erişebildiği her şeyi, profil dizininizdeki cookie değerleri dahil, okuyabilir. Servisi 127.0.0.1 üzerinde tutun. Başka bir makineden erişmek için SSH tunnel (ssh -L 9222:127.0.0.1:9222 user@your-vps) veya private VPN arayüzü kullanın ve agent'ın kendi tarafında http://127.0.0.1:9222 adresine bağlanmasını sağlayın.

Bir servis kullanıcısı oluşturun, ardından unit dosyasını oluşturun:

sudo useradd --system --home-dir /var/lib/moli --shell /usr/sbin/nologin moli

/etc/systemd/system/moli.service dosyasını yazın:

[Unit]
Description=Moli headless browser CDP server
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=moli
Group=moli
ExecStart=/usr/local/bin/moli serve --host 127.0.0.1 --port 9222 --profile-dir /var/lib/moli/profile --block-private-networks
Restart=on-failure
RestartSec=2
StateDirectory=moli
MemoryAccounting=yes
MemoryMax=768M
NoNewPrivileges=yes
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=strict

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now moli.service
systemctl status moli.service
curl -s http://127.0.0.1:9222/json/version

systemctl status çıktısında active (running) görünmelidir. curl ise discovery JSON verisini döndürmelidir. ProtectSystem=strict bu unit için tüm dosya sistemini salt okunur olarak mount eder. Bu nedenle StateDirectory=moli burada isteğe bağlı değildir: servis kullanıcısının sahip olduğu /var/lib/moli dizinini oluşturur ve yalnızca bu yolu yazılabilir hale getirir. Başlayıp ardından journalctl -u moli içinde permission error ile sonlanan bir unit, neredeyse her zaman ProtectSystem tarafından salt okunur hale getirilen bir konuma yazmaya çalışıyordur. Bu yolu state directory altına taşıyın.

MemoryMax=768M, bu servisin uygulamanızın yanında güvenli biçimde çalıştırılmasını sağlar. Unit kendisine ait bir cgroup alır. Bu cgroup limitini aştığında kernel içindeki bir süreci sonlandırır ve sunucunun geri kalanını etkilemez. journal bu olayı kaydeder:

moli.service: A process of this unit has been killed by the OOM killer.

Bu satırı boyutlandırma için bir sinyal olarak değerlendirin. Sayfalar planladığınızdan daha ağır olabilir veya limit çok düşük olabilir. Değeri kendi sayfalarınızdan alacağınız bir ölçüme göre belirleyin. Bu işlem sonraki bölümde açıklanır. Aynı accounting flag'leri sunucudaki diğer servisleri de kendi sınırları içinde tutar. systemd ile bellek ve CPU kullanımını sınırlandırma başlığı, bu servislerin geri kalanı için de aynı mekanizmayı kullanır.

Tepe bellek kullanımını kendiniz ölçün

Yayımlanan değerler başka birinin donanımından ve başka sayfalardan elde edilmiştir. Sunucunuzun çalışmaya devam edip edemeyeceğini tepe bellek kullanımı belirler ve tepe değer tamamen ne yüklediğinize bağlıdır. Boyutlandırma yapmadan önce ölçüm alın.

Tek seferlik veri çekme işlemleri için aynı adlı shell builtin komutundan çok daha fazla bilgi raporlayan time binary dosyasını kullanın:

sudo apt update && sudo apt install -y time
/usr/bin/time -v moli fetch --dump markdown --wait-until networkidle https://example.com > /dev/null

Çıktı, Maximum resident set size (kbytes) değerini de içeren bir kaynak istatistikleri bloğuyla sona erer. MiB değerini elde etmek için bu değeri 1024'e bölün. Ölçümü example.com üzerinde değil, agent'ınızın gerçekten ziyaret ettiği on sayfa üzerinde gerçekleştirin ve ortalama yerine en yüksek sonucu kullanın; çünkü OOM killer tepe değerlerine göre tepki verir.

Servis için kernel'ın cgroup kapsamında tuttuğu sayacı okuyun:

cat /sys/fs/cgroup/system.slice/moli.service/memory.peak
systemd-cgtop -m

memory.peak byte cinsinden bir sayıdır ve unit en son başlatıldığından beri görülen en yüksek değeri gösterir; dolayısıyla yeniden başlatma bu değeri sıfırlar. MemoryMax değeri, henüz ziyaret etmediğiniz en ağır sayfa için ek pay bırakılarak bu değerin üzerinde olmalıdır. systemd-cgtop -m her unit için anlık kullanımı gösterir ve sunucudaki hangi servisin bugün en fazla kaynak tükettiğini görmenin en hızlı yoludur.

Moli nerede başarısız olur ve Chrome'a ne zaman ihtiyaç duyulur?

Proje ayrıca karşılaştırılabilir 1,308 tarayıcı otomasyonu görevi üzerinde bir benchmark çalıştırır ve çeşitli engine'ler için skoru yayımlar.

[
  {
    "engine": "Chrome",
    "success_rate_pct": 99.85
  },
  {
    "engine": "Moli 0.1.1",
    "success_rate_pct": 81.88
  },
  {
    "engine": "Kitesurf",
    "success_rate_pct": 62.08
  },
  {
    "engine": "Lightpanda",
    "success_rate_pct": 53.29
  },
  {
    "engine": "Obscura",
    "success_rate_pct": 44.88
  }
]

5 engine arasında Moli 0.1.1 görevlerin 81.88 yüzdesini tamamlarken referans engine olan Chrome, görevlerin 99.85 yüzdesini tamamladı. Bu, projenin kendi test grubunda yaptığı bir puanlamadır. Bu nedenle bağımsız bir sonuçtan çok proje iddiası olarak değerlendirilmelidir.

Pratik sonuç basittir. Chrome'un tamamladığı yaklaşık her beş görevden biri Moli'de başarısız oldu. Agent'ınız yalnızca kontrol ettiğiniz sabit bir sayfa kümesini ziyaret ediyorsa bu oran fazla bilgi vermez. Sayfalarınız ya çalışır ya da çalışmaz ve sonucu aynı gün öğrenebilirsiniz. Agent'ınız açık web'de gezinüyorsa bu, tasarımda dikkate alınması gereken gerçek bir hata oranıdır.

Başarısızlıkların nedeni, projenin belirttiği kapsamdan öngörülebilir.

• Arayüzünü DOM yerine Canvas elementine çizen uygulamalar; çünkü Canvas doğruluğu açıkça kapsam dışıdır
• WebGL veya GPU compositing gerektiren her şey; çünkü GPU compositor bulunmaz
• DRM korumalı video ve yüksek kaynak gerektiren medya oynatma
• Chrome ile piksel düzeyinde birebir ekran görüntüsü eşleşmesi doğrulayan görsel testler; çünkü Chrome ile parity sağlamak hedef değildir

Projenin belirttiği diğer rakam, tek bir tam çalıştırmada 1.612 milyon web platform testinin geçmesi, standart kapsamıyla ilgilidir. Bu, agent'ınızın ziyaret edeceği siteler için bir garanti değildir. Bir sayfa yalnızca iyi desteklenen standartları kullansa bile bot kontrolünde başarısız olabilir. Hiçbir engine skoru bu durumu kapsamaz.

Bu nedenle tasarımda fallback bulundurun. Her URL'yi önce Moli'ye gönderin. Bir sayfa boş dönerse veya bir selector hiç görünmezse, o URL'yi Playwright ile gerçek Chrome'u çalıştırarak yeniden deneyin. Bu işlemi daha büyük bir makinede veya 773 MiB boyutundaki bir sürecin karşılanabildiği bir zamanlamayla yapın. Agent'ların çoğu zamanını sıradan sayfalarda geçirir. Bu nedenle küçük engine hacmi taşırken pahalı engine uç durumları ele alır.

FAQ

Moli, aracım için headless Chrome'un yerini alabilir mi?

Sayfa okuma, metin ayıklama ve standart tıklama işlemleri için genellikle evet. Projenin kendi 1.308 görevlik kıyaslama testinde, Chrome'un 99.85 yüzdelik başarı oranına karşılık 81.88 yüzdelik başarı oranı yakalanmıştır; yani yaklaşık her beş görevden biri Moli'nin desteklemediği bir özellik gerektirmektedir. Canvas ile oluşturulan uygulamalar, WebGL ve DRM içerikli videolar bilinen eksiklerdir. Bu tür URL'leri her şeyi geri çevirmek yerine gerçek bir Chrome tarayıcısına yönlendirin.

Moli bir VPS üzerinde ne kadar RAM tüketir?

Proje, 192 URL'lik bir tarama genelinde 73 MiB medyan RSS ve örnek bir aracı bölümünde 102.46 MiB tepe PSS değeri raporlamaktadır; headless Chrome için bu değer 773 MiB medyan seviyesindedir. Bunlar kendi sayfalarındaki verilerdir. Tek seferlik kullanımlar için /usr/bin/time -v komutunu bir moli fetch çağrısı etrafında kullanarak veya servis için /sys/fs/cgroup/system.slice/moli.service/memory.peak dosyasını okuyarak kendi değerlerinizi ölçün, ardından MemoryMax değerini gözlemlediğiniz en yüksek rakamın üzerinde bir seviyeye ayarlayın.

9222 numaralı portu internete açmak güvenli midir?

Hayır. CDP kimlik doğrulama içermez; bu nedenle portunuza erişebilen herkes tarayıcınızı yönetebilir ve tarayıcının erişebildiği her şeyi okuyabilir. --host 127.0.0.1 kuralını koruyun ve uç noktaya başka bir makineden SSH tüneli veya özel bir VPN arayüzü üzerinden erişin. Başka bir adrese bağlamanız gerekiyorsa, bunu özel bir arayüzde tutun ve erişimi güvenlik duvarı ile denetleyin.

Neden ekran görüntüm boş veya tıklamam hiçbir yere denk gelmiyor?

Düzen (layout) varsayılan olarak kapalıdır. README dosyası varsayılan politikayı LayoutPolicy::Mock olarak belirtir; bu nedenle öğe geometrisi gerçek değildir ve sayfadaki bir kutuya bağlı olan her şey işlevsiz kalır. Sunucuyu moli serve --layout ile başlatın veya moli fetch dosyasına --layout ekleyin; böylece ekran görüntüsü ve koordinat yolları çalışmaya başlayacaktır. Eksik görseller farklı bir bayrakla ilgilidir: --resource.

Moli'nin hangi sürümünü yüklemeliyim?

Bir sürümü sabitleyin ve hangisini kullandığınızı kaydedin. 20 Ekim 2026 itibarıyla en yeni sürüm 1.1.18'dir ve birkaç günde bir yeni sürümler yayınlanmaktadır. Projenin Lexbench puanı 0.1.1 sürümünde ölçülmüştür; bu nedenle başkalarıyla notlarınızı karşılaştırmadan önce sürümleri kontrol edin. İlgili etiketin moli-x86_64-unknown-linux-gnu.tar.gz dosyasını indirin ve ikili dosyayı, en yeni sürümü çözümleyen shell yükleyicisine güvenmek yerine kendiniz kurun, ardından moli --version ile doğrulayın.