Moli: lekka alternatywa dla headless Chrome na VPS

Headless browser o niskim zapotrzebowaniu na zasoby dla małych VPS

Moli to headless browser przeznaczony dla agentów AI, wystarczająco lekki, aby uruchomić go na serwerze VPS, na którym instalacja headless Chrome jest niemożliwa. Silnik przeglądarki został napisany w języku Rust i nie stanowi nakładki na Chromium. Obsługuje protokół Chrome DevTools Protocol (CDP), z którym współpracują obecnie używane biblioteki automatyzacji. Instalacja sprowadza się do pobrania jednego pliku binarnego, uruchomienia moli serve, a następnie wskazania Playwright lub własnego kodu agenta na http://127.0.0.1:9222.

Przed instalacją należy zapoznać się z ograniczeniami. Projekt jasno określa swój zakres: brak interfejsu graficznego, brak kompozytora GPU, brak pełnej zgodności z Chrome w renderowaniu pikseli oraz brak obsługi Canvas o wysokiej wierności czy odtwarzania multimediów. Strony wymagające tych funkcji nie będą działać poprawnie. Pełna wersja Chrome w połączeniu z Playwright pozostaje rozwiązaniem alternatywnym, a ostatnia sekcja zawiera wskazówki, jak ocenić, które strony wymagają pełnego silnika.

Wszystkie poniższe polecenia pochodzą z pliku README projektu oraz opublikowanych plików konfiguracyjnych, zweryfikowanych w sierpniu 2026 roku. Wszystkie liczby w tabelach to dane opublikowane przez twórców projektu dotyczące ich silnika, a nie pomiary wykonane przez niniejszy serwis, co zaznaczono w podpisach pod wykresami. Jeśli wybór silnika jest nadal w toku, szersze zestawienie headless browserów dla agentów na VPS zawiera dostępne alternatywy.

Dlaczego headless Chrome zużywa tak dużo pamięci?

Chrome jest przeglądarką wieloprocesową. Każda karta oraz każda ramka iframe pochodząca z innej domeny otrzymuje własny proces renderujący, a każdy renderer posiada własny stos V8 oraz bufory graficzne. Taka architektura jest odpowiednia dla komputerów stacjonarnych, gdzie awaria jednej karty nie powinna powodować zamknięcia całego okna. Na serwerze VPS z 2 GB pamięci RAM oznacza to, że pojedyncza operacja przeglądania może pochłonąć więcej pamięci niż sama uruchomiona aplikacja.

W ramach projektu przeszukano 192 publiczne adresy URL przy użyciu czterech silników i opublikowano wyniki.

[
  {
    "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 zwrócił 101 użytecznych stron, a Moli zwrócił 103, więc w tej próbie oba silniki odczytały zbliżony odsetek zasobów sieciowych. Różnice uwidaczniają się w zużyciu pamięci: mediana RSS (resident set size, czyli pamięć faktycznie zajmowana przez proces w RAM) wyniosła 773 MiB dla Chrome w porównaniu do 73 MiB dla Moli. Ten kierunek jest wiarygodny, ponieważ wynika bezpośrednio z architektury procesów. Nie należy zakładać, że dokładny stosunek zużycia pamięci będzie identyczny w przypadku własnych stron.

To nie mediana jest wartością najbardziej problematyczną, lecz wartość szczytowa. Gdy serwer z 2 GB pamięci wyczerpie zasoby, jądro systemu wybiera proces i kończy jego działanie, a wpis o tym zdarzeniu trafia do dmesg -T lub journalctl -k:

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

Agent nie otrzymuje informacji o tym zdarzeniu. Widzi jedynie przeglądarkę, która przestała odpowiadać, zazwyczaj w postaci błędu Playwright, takiego jak page.goto: Page crashed lub zamkniętego celu (closed target). Żaden z tych komunikatów nie wspomina o pamięci, dlatego mechanizm OOM (out of memory) killer jest pierwszym elementem, który należy sprawdzić, gdy agent losowo zawodzi na małym serwerze. Dobór zasobów pod kątem wartości szczytowych to to samo zadanie, co dobór pamięci RAM i procesora dla serwera VPS z agentem.

Instalacja pliku binarnego Moli z przypięciem wersji

Projekt publikuje instalator powłoki oraz gotowe archiwa tarball w sekcji GitHub releases. Według stanu na sierpień 2026 r. bieżące wydanie to 1.0.1, opublikowane 18 sierpnia 2026 r. Wyniki testów wydajnościowych przytoczone w tym przewodniku zostały zmierzone przez autorów projektu na wersji 0.1.1, dlatego należy traktować je jako przybliżony obraz możliwości silnika, a nie gwarancję dla instalowanej wersji.

Przypnij wersję. Instalator, który zawsze pobiera latest, przy kolejnej przebudowie przeniesie agenta na inny silnik przeglądarki, a zmiana zachowania przeglądarki jest rodzajem zmiany, którą należy zaplanować, a nie odkrywać przypadkiem.

Instalator powłoki to najszybsza metoda, jednak warto go przeczytać, zanim zostanie uruchomiony.

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

Przeczytaj skrypt przed uruchomieniem. Jest krótki. Pobiera archiwum z uname -m, a następnie rozpakowuje pojedynczy plik binarny do ~/.local/bin. Na architekturze x86_64 pobiera moli-x86_64-unknown-linux-gnu.tar.gz, a na serwerze Arm pobiera archiwum aarch64, dzięki czemu obsługiwane są plany VPS zarówno dla Arm, jak i x86. Ustaw MOLI_INSTALL_DIR, aby zainstalować oprogramowanie w innej lokalizacji. Zwróć uwagę, co skrypt wybiera jako wersję: najnowsze wydanie, a nie tag, z którego pobrano skrypt. Jest to dopuszczalne przy pierwszym sprawdzeniu, ale niewłaściwe w przypadku przebudowy, która ma być powtarzalna.

Dlatego w przypadku instalacji stałych wykonaj ręcznie czynności, które wykonuje instalator, i samodzielnie wskaż konkretne archiwum. Jest to również sposób na umieszczenie pliku binarnego w miejscu dostępnym dla usługi systemowej oraz pozwala uniknąć przesyłania pobranego skryptu bezpośrednio do powłoki.

cd /tmp
curl --proto '=https' --tlsv1.2 -fsSLO \
  https://github.com/lexmount/moli/releases/download/v1.0.1/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 wyświetlające przypiętą wersję stanowi pełną weryfikację. moli: command not found bezpośrednio po instalatorze oznacza, że katalog instalacyjny nie znajduje się w PATH, a instalator wyświetla linię wskazującą katalog, który należy dodać.

Jednorazowe pobieranie danych za pomocą moli fetch

Wiele zadań zlecanych przez agenta przeglądarce sprowadza się do polecenia „wczytaj ten URL i przekaż jego treść”. Nie wymaga to uruchamiania żadnego serwera. moli fetch uruchamia silnik, wczytuje jedną stronę, zapisuje jeden artefakt na standardowe wyjście i kończy działanie, dzięki czemu pamięć nie jest zajmowana pomiędzy wywołaniami.

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

Pierwsze polecenie wyświetla stronę w formacie Markdown, zaczynając od # Example Domain. Markdown jest najbardziej ekonomicznym formatem dla modelu, ponieważ usuwa znaczniki, pozostawiając sam tekst. semantic_tree_text zachowuje role i strukturę, co jest przydatne na stronach z rozbudowaną nawigacją, gdzie linki są równie ważne co treść. --dump json zawiera status HTTP oraz ślad żądania; należy po nie sięgnąć, gdy pobieranie zwraca pusty wynik i konieczne jest ustalenie przyczyny.

Strategia oczekiwania decyduje o tym, czy otrzymasz zawartość, czy pustą powłokę. --wait-until networkidle kończy działanie, gdy sieć staje się bezczynna. --wait-until domstable kończy działanie, gdy DOM przestaje się zmieniać, co jest lepszym wyborem w przypadku stron z aktywnym odpytywaniem w tle, które nigdy nie przechodzą w stan bezczynności. --wait-selector czeka na wskazany selektor. Jest to jedyna strategia, która posiada wiedzę o pobieranej stronie, co czyni ją najbardziej niezawodną, gdy cel jest znany.

Zrzuty ekranu i pliki PDF wymagają poprawnego renderowania układu, który jest domyślnie wyłączony:

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

Plik README określa domyślną politykę układu jako LayoutPolicy::Mock: geometria jest symulowana, a renderowanie nie jest wykonywane, ponieważ układ i malowanie są najbardziej zasobożernymi procesami przeglądarki. To ustawienie jest powodem, dla którego powyższe wartości zużycia pamięci są tak niskie. Oznacza to również, że pusty plik PNG zazwyczaj wynika z braku flagi --layout, a nie z błędu strony.

W przypadku adresów URL znalezionych przez agenta, a nie wybranych przez użytkownika, należy dodać --block-private-networks. Agent podążający za linkami znalezionymi na stronie może zostać nakierowany na pobranie http://169.254.169.254/ z poświadczeniami instancji chmurowej lub portu bazy danych na localhost, który nie powinien być dostępny publicznie. Flaga ta blokuje nawigację do prywatnej przestrzeni adresowej, a --block-cidrs dodatkowo ją zawęża. Gdy zadanie polega na indeksowaniu, a nie na odczycie pojedynczej strony, struktura takiego potoku została opisana w alternatywy dla Firecrawl hostowane samodzielnie, a wcześniejszy etap, czyli wyszukiwanie adresów URL, został omówiony w umiejętność wyszukiwania dla agentów oparta na SearXNG.

Wskazywanie agenta na Moli przez CDP

W przypadku agenta, który nawiguje i klika w wielu krokach, należy uruchomić serwer.

moli serve --host 127.0.0.1 --port 9222

127.0.0.1 oraz port 9222 to wartości domyślne, więc samo moli serve wiąże się tylko z interfejsem loopback. Warto jednak zawsze zapisywać obie te wartości w konfiguracjach trwałych, aby osoba czytająca plik usługi nie musiała pamiętać ustawień domyślnych.

Przed podłączeniem klienta należy sprawdzić stan serwera:

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

Poprawnie działający serwer odpowiada obiektem JSON zawierającym pole webSocketDebuggerUrl; to właśnie ten URL służy do podłączenia klienta CDP. Błąd curl: (7) Failed to connect to 127.0.0.1 port 9222: Connection refused oznacza, że nikt nie nasłuchuje na porcie, więc należy sprawdzić terminal, w którym uruchomiono proces, lub użyć journalctl -u moli -n 50, jeśli usługa działa w tle. /json/list wyświetla listę otwartych celów, a /json/protocol listę domen zaimplementowanych w danej kompilacji; pozwala to sprawdzić, czy wymagana metoda CDP jest dostępna.

Playwright łączy się z tym punktem końcowym zamiast uruchamiać własną instancję przeglądarki:

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();

Kluczowa jest linia connectOverCDP, a nie chromium.launch(). W tym trybie nie istnieje proces potomny Chromium, więc executablePath oraz typowe flagi kontenerowe, takie jak --no-sandbox, nie mają zastosowania. Z tego samego powodu ustawienia proxy, plików cookie oraz user-agent należy przekazywać jako flagi serwera Moli. Należy spodziewać się wybranego wsparcia dla CDP, a nie pełnej obsługi protokołu Chrome: jawny błąd unsupported-method oznacza ograniczenie silnika, a nie błąd w kodzie.

Działanie agenta określają dwie flagi serwera. --layout włącza rzeczywistą geometrię, niezbędną do kliknięć według współrzędnych oraz zrzutów ekranu. --resource pobiera opcjonalne obrazy, czcionki i multimedia; zwiększa to zużycie pasma oraz pamięci przy każdym ładowaniu strony, dlatego należy pozostawić tę opcję wyłączoną, dopóki strona nie wymaga tych zasobów. --profile-dir zapewnia trwałość plików cookie i pamięci między uruchomieniami; bez tej flagi każde uruchomienie jest traktowane jako sesja jednorazowa.

[
  {
    "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
  }
]

W przykładowym obciążeniu agenta Moli zaakceptował połączenie CDP po 34.85 ms w porównaniu do 169.37 ms dla Chromium, przy szczytowym PSS (proportional set size, pamięć liczona z uwzględnieniem stron współdzielonych między procesami) wynoszącym 102.46 MiB w porównaniu do 348.82 MiB. Różnica strukturalna widoczna jest w ostatniej kolumnie: 1 proces w porównaniu do 11. Jeden proces to jeden obiekt do nadzorowania przez systemd i jedna grupa cgroup do ograniczenia zasobów, co sprawia, że kolejna sekcja jest krótka.

Uruchamianie moli serve jako usługi systemd na interfejsie loopback

Uruchom serwer jako usługę, gdy agent wymaga oczekującej przeglądarki. W przeciwnym razie używaj moli fetch dla każdego adresu URL, ponieważ bezczynny serwer nadal zajmuje pamięć.

Nie wystawiaj portu 9222 na publicznym interfejsie. Protokół CDP nie posiada żadnego mechanizmu uwierzytelniania. Każdy, kto uzyska dostęp do tego portu, może sterować przeglądarką i odczytywać wszystko, do czego ma ona dostęp, włącznie z plikami cookie w katalogu profilu. Pozostaw usługę na 127.0.0.1. Uzyskuj do niej dostęp z innej maszyny poprzez tunel SSH (ssh -L 9222:127.0.0.1:9222 user@your-vps) lub prywatny interfejs VPN, pozwalając agentowi łączyć się z http://127.0.0.1:9222 po jego stronie tunelu.

Utwórz użytkownika systemowego, a następnie plik jednostki:

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

Zapisz /etc/systemd/system/moli.service:

[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 powinno pokazać active (running), a curl powinno zwrócić plik JSON z informacjami o wykrywaniu. ProtectSystem=strict montuje cały system plików w trybie tylko do odczytu dla tej jednostki, dlatego StateDirectory=moli nie jest tutaj opcjonalne: tworzy ono /var/lib/moli, którego właścicielem jest użytkownik usługi, i czyni tę ścieżkę zapisywalną. Jednostka, która uruchamia się, a następnie kończy działanie z błędem uprawnień w journalctl -u moli, niemal zawsze próbuje zapisać dane w miejscu, które ProtectSystem właśnie uczyniło dostępnym tylko do odczytu, więc przenieś tę ścieżkę do katalogu stanu.

MemoryMax=768M sprawia, że uruchamianie usługi obok aplikacji jest bezpieczne. Jednostka otrzymuje własną grupę kontrolną (cgroup), a gdy przekroczy ona limit, jądro systemu zabija proces wewnątrz niej, pozostawiając resztę systemu w spokoju. Dziennik systemd rejestruje to zdarzenie:

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

Traktuj ten wiersz jako sygnał dotyczący zapotrzebowania na zasoby. Strony są cięższe niż zakładano lub limit jest zbyt niski. Ustaw wartość na podstawie pomiaru własnych stron, co opisano w następnej sekcji. Te same flagi rozliczeniowe ograniczają każdą inną usługę na serwerze, a ograniczanie pamięci i procesora za pomocą systemd wyjaśnia pozostałe z nich.

Samodzielny pomiar szczytowego zużycia pamięci

Opublikowane dane pochodzą z cudzego sprzętu i innych zestawów stron. Szczytowe zużycie pamięci decyduje o tym, czy serwer przetrwa, a wartość ta zależy wyłącznie od ładowanej zawartości. Należy dokonać pomiarów przed doborem zasobów.

Do jednorazowego pobierania danych należy użyć pliku binarnego time, który raportuje znacznie więcej informacji niż wbudowane polecenie powłoki o tej samej nazwie:

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

Dane wyjściowe kończą się blokiem statystyk zasobów, który zawiera Maximum resident set size (kbytes). Wartość tę należy podzielić przez 1024, aby uzyskać wynik w MiB. Test należy przeprowadzić dla dziesięciu stron, które faktycznie odwiedza agent, zamiast dla example.com, i zachować najgorszy wynik zamiast średniej, ponieważ mechanizm OOM killer reaguje na wartości szczytowe.

W przypadku usługi należy odczytać licznik utrzymywany przez jądro dla danej cgroup:

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

memory.peak to liczba bajtów określająca najwyższy odnotowany poziom zużycia od ostatniego uruchomienia jednostki, zatem restart resetuje ten licznik. Wartość ta stanowi dolną granicę, powyżej której musi znajdować się MemoryMax, z uwzględnieniem zapasu na najcięższą stronę, która nie została jeszcze odwiedzona. systemd-cgtop -m pokazuje bieżące zużycie dla każdej jednostki, co jest najszybszym sposobem na zidentyfikowanie usługi, która w danym dniu najbardziej obciąża serwer.

Gdzie Moli zawodzi i kiedy nadal potrzebny jest Chrome?

Projekt przeprowadza również benchmark 1308 porównywalnych zadań automatyzacji przeglądarki i publikuje wyniki dla kilku silników.

[
  {
    "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
  }
]

Wśród tych 5 silników, Moli 0.1.1 ukończył 81.88 procent zadań, a Chrome, jako silnik referencyjny, ukończył 99.85 procent. Jest to wynik projektu oceniającego samego siebie w ramach własnego zestawu testów, więc należy go traktować jako deklarację, a nie niezależny wynik.

Praktyczna interpretacja jest prosta. Mniej więcej jedno na pięć zadań, które Chrome wykonał poprawnie, zakończyło się niepowodzeniem w Moli. Jeśli agent odwiedza stały zestaw stron, nad którymi sprawujesz kontrolę, ten wskaźnik ma niewielkie znaczenie, ponieważ strony albo działają, albo nie, co można zweryfikować w krótkim czasie. Jeśli jednak agent przegląda otwartą sieć, jest to realny wskaźnik awaryjności, który należy uwzględnić w projekcie.

Przyczyny niepowodzeń są przewidywalne i wynikają z zakresu określonego przez projekt.

• Aplikacje renderujące interfejs w elemencie Canvas zamiast w DOM, ponieważ wierność odwzorowania Canvas jest jawnie poza zakresem projektu.
• Wszystko, co wymaga WebGL lub kompozycji GPU, ponieważ brak jest kompozytora GPU.
• Treści wideo chronione DRM oraz wymagające odtwarzanie multimediów.
• Testy wizualne, które wymagają zrzutów ekranu identycznych co do piksela z Chrome, ponieważ osiągnięcie pełnej zgodności z Chrome nie jest celem projektu.

Druga liczba przytaczana przez projekt, czyli 1,612 miliona zaliczonych testów platformy internetowej, dotyczy pokrycia standardów. Nie jest to gwarancja poprawnego działania na stronach, które odwiedzi agent. Strona może korzystać wyłącznie z dobrze wspieranych standardów, a mimo to zostać zablokowana przez mechanizmy wykrywające boty, czego nie obejmuje żaden wynik silnika.

Dlatego należy zachować mechanizm awaryjny w projekcie. Każdy adres URL należy najpierw skierować do Moli. Jeśli strona zwróci pustą treść lub selektor nie pojawi się, należy ponowić próbę dla tego konkretnego adresu URL przy użyciu Playwright sterującego pełnym Chrome, na mocniejszej maszynie lub w harmonogramie, w którym proces o rozmiarze 773 MiB jest akceptowalny. Większość agentów spędza większość czasu na typowych stronach, więc lekki silnik obsługuje główny wolumen ruchu, a cięższy silnik przejmuje pozostałe przypadki.

FAQ

Czy Moli może zastąpić headless Chrome w moim agencie?

W przypadku odczytu stron, ekstrakcji tekstu i standardowych kliknięć zazwyczaj tak. W autorskim benchmarku projektu obejmującym 1308 zadań, narzędzie osiągnęło 81.88 procent skuteczności wobec 99.85 procent dla Chrome, co oznacza, że mniej więcej jedno na pięć zadań wymaga funkcji, których Moli nie posiada. Znane braki obejmują aplikacje renderowane w Canvas, WebGL oraz wideo z DRM. Takie adresy URL należy kierować do pełnego Chrome, zamiast przywracać całą konfigurację.

Ile pamięci RAM wymaga Moli na serwerze VPS?

Projekt podaje medianę RSS na poziomie 73 MiB przy indeksowaniu 192 adresów URL oraz szczytowe PSS rzędu 102.46 MiB podczas przykładowej sesji agenta, w porównaniu do 773 MiB mediany dla headless Chrome. Są to wartości deklarowane przez autorów. Należy zmierzyć własne zużycie za pomocą /usr/bin/time -v wokół wywołania moli fetch dla użycia jednorazowego lub odczytać /sys/fs/cgroup/system.slice/moli.service/memory.peak dla usługi, a następnie ustawić MemoryMax powyżej najwyższej zaobserwowanej wartości.

Czy bezpieczne jest wystawienie portu 9222 do Internetu?

Nie. Protokół CDP nie posiada mechanizmów uwierzytelniania, więc każdy, kto uzyska dostęp do tego portu, może przejąć kontrolę nad przeglądarką i odczytać wszystko, do czego ma ona dostęp. Należy zachować --host 127.0.0.1 i łączyć się z punktem końcowym z innej maszyny poprzez tunel SSH lub prywatny interfejs VPN. Jeśli konieczne jest powiązanie z innym adresem, należy użyć interfejsu prywatnego i ograniczyć dostęp za pomocą firewalla.

Dlaczego zrzut ekranu jest pusty lub kliknięcia nie trafiają w cel?

Układ strony jest domyślnie wyłączony. Plik README wskazuje domyślną politykę LayoutPolicy::Mock, przez co geometria elementów nie jest rzeczywista, a funkcje zależne od wymiarów obiektów na stronie nie działają. Należy uruchomić serwer z flagą moli serve --layout lub dodać --layout do moli fetch, aby zrzuty ekranu i ścieżki współrzędnych zaczęły działać. Brakujące obrazy wynikają z innej flagi: --resource.

Którą wersję Moli należy zainstalować?

Należy przypiąć konkretną wersję i odnotować jej numer. Według stanu na sierpień 2026 bieżące wydanie to 1.0.1, podczas gdy wyniki benchmarków publikowane przez projekt mierzono na wersji 0.1.1, więc obie wersje nie są zamienne przy porównywaniu wyników z innymi użytkownikami. Należy pobrać moli-x86_64-unknown-linux-gnu.tar.gz dla danego tagu i zainstalować plik binarny samodzielnie, zamiast polegać na instalatorze powłoki, który pobiera najnowsze wydanie zamiast konkretnego tagu, a następnie potwierdzić wersję za pomocą moli --version.