SSD Nodes Learn 🎉 VPS $5.50/माह से
गाइड Matt Connorलेखक: Matt Connor · अपडेट किया गया: 2026-08-21

Moli headless browser को VPS पर कैसे install करें

छोटे VPS पर Headless Chrome भारी पड़ता है। Moli का उपयोग करके CDP को loopback पर चलाएं और अपने AI agents को कनेक्ट करें। जानें कि यह टूल किन वेबसाइटों पर काम नहीं करता है।

एक headless browser जो छोटे VPS पर फिट बैठता है

Moli AI agents के लिए एक headless browser है, और यह इतना छोटा है कि इसे ऐसे VPS पर self-host किया जा सकता है जहाँ headless Chrome फिट नहीं होगा। यह Rust में लिखा गया एक browser engine है, न कि Chromium का कोई wrapper, और यह Chrome DevTools Protocol (CDP) का जवाब देता है, वही protocol जिसे आपकी automation library पहले से ही समझती है। आप एक binary install करते हैं, moli serve चलाते हैं, और फिर Playwright या अपने agent code को http://127.0.0.1:9222 पर point करते हैं।

कुछ भी install करने से पहले trade-off को समझें। यह project अपना दायरा स्पष्ट रूप से बताता है: कोई GUI browser नहीं, कोई GPU compositor नहीं, Chrome के साथ pixel-for-pixel समानता नहीं, और न ही उच्च गुणवत्ता वाला Canvas या media playback। जिन pages को इनकी आवश्यकता होती है, वे fail हो जाएंगे। Playwright के अंतर्गत वास्तविक Chrome ही fallback बना रहेगा, और अंतिम section आपको यह दिखाएगा कि किन pages के लिए इसकी आवश्यकता है।

नीचे दिए गए सभी commands project के README और उसकी प्रकाशित skill files से लिए गए हैं, जिन्हें अगस्त 2026 में जाँचा गया था। charts में दिए गए सभी numbers वे आंकड़े हैं जिन्हें project ने अपने engine के बारे में प्रकाशित किया है, न कि इस site द्वारा मापे गए आंकड़े, और प्रत्येक chart caption में यह बात लिखी है। यदि आप अभी भी एक engine चुन रहे हैं, तो VPS पर agents के लिए headless browsers का व्यापक सर्वेक्षण अन्य विकल्पों को कवर करता है।

Headless Chrome इतनी अधिक मेमोरी का उपयोग क्यों करता है?

Chrome एक multi-process browser है। प्रत्येक tab और प्रत्येक cross-site iframe की अपनी renderer process होती है, और प्रत्येक renderer का अपना V8 heap और graphics buffers होते हैं। यह डिज़ाइन desktop के लिए सही है, जहाँ एक tab क्रैश होने पर पूरी window बंद नहीं होनी चाहिए। 2 GB के VPS पर इसका मतलब है कि एक single browse step उस application से अधिक मेमोरी ले सकता है जिसे आप वास्तव में चला रहे हैं।

प्रोजेक्ट ने चार engines के साथ 192 मिश्रित public URLs को crawl किया और परिणाम प्रकाशित किए।

ChartMixed public web crawl, 192 URLs, figures published by the Moli project
The data behind this chart
[
  {
    "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 उपयोगी pages लौटाए और Moli ने 103 लौटाए, इसलिए उस sample पर दोनों engines ने web का लगभग समान हिस्सा पढ़ा। मेमोरी वह जगह है जहाँ वे अलग हो जाते हैं: Chrome के लिए 773 MiB का median RSS (resident set size, वह मेमोरी जिसे एक process वास्तव में RAM में रखती है) बनाम Moli के लिए 73 MiB। यह अंतर विश्वसनीय है क्योंकि यह process architecture के कारण है। आपके pages पर सटीक अनुपात क्या होगा, यह मानकर न चलें।

Median वह संख्या नहीं है जो आपको नुकसान पहुँचाती है। Peak (अधिकतम) संख्या नुकसान पहुँचाती है। जब 2 GB का box मेमोरी से बाहर हो जाता है, तो kernel एक process चुनता है और उसे kill कर देता है, और इसका record dmesg -T या 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 वह line कभी नहीं देखता। वह एक ऐसा browser देखता है जिसने जवाब देना बंद कर दिया है, आमतौर पर Playwright error के रूप में जैसे कि page.goto: Page crashed या एक closed target। उस error में कहीं भी मेमोरी का उल्लेख नहीं होता है, यही कारण है कि जब कोई agent छोटे box पर रैंडम तरीके से fail होता है, तो OOM (out of memory) killer सबसे पहली चीज़ है जिसे check करना चाहिए। Peak के लिए sizing करना वैसा ही है जैसे agent VPS के लिए RAM और CPU चुनना।

Moli बाइनरी इंस्टॉल करें, एक विशिष्ट वर्ज़न पर पिन करें

यह प्रोजेक्ट GitHub releases पर एक शेल इंस्टॉलर और पहले से बनी tarballs प्रकाशित करता है। अगस्त 2026 तक, वर्तमान रिलीज़ 1.0.1 है, जिसे 18 अगस्त 2026 को प्रकाशित किया गया था। इस गाइड में दिए गए बेंचमार्क आंकड़े प्रोजेक्ट द्वारा 0.1.1 पर मापे गए थे, इसलिए उन्हें इंजन की एक अनुमानित क्षमता मानें, न कि आपके द्वारा इंस्टॉल किए जाने वाले बिल्ड के बारे में कोई गारंटी।

वर्ज़न को पिन करें। जो इंस्टॉलर हमेशा latest को रिज़ॉल्व करता है, वह अगले रीबिल्ड पर आपके एजेंट को एक अलग ब्राउज़र इंजन पर ले जाता है। ब्राउज़र के व्यवहार में बदलाव ऐसी चीज़ है जिसे आप खुद शेड्यूल करना चाहेंगे, न कि अचानक खोजना।

शेल इंस्टॉलर सबसे तेज़ तरीका है, और इसे चलाने से पहले इसे पढ़ना उचित है।

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

स्क्रिप्ट को चलाने से पहले उसे पढ़ें। यह छोटी है। यह आपके uname -m से एक आर्काइव चुनती है, और फिर एक सिंगल बाइनरी को ~/.local/bin में अनपैक करती है। x86_64 पर यह moli-x86_64-unknown-linux-gnu.tar.gz लेती है, और Arm सर्वर पर यह aarch64 आर्काइव लेती है, इसलिए Arm और x86 VPS प्लान दोनों कवर हो जाते हैं। कहीं और इंस्टॉल करने के लिए MOLI_INSTALL_DIR सेट करें। ध्यान दें कि यह वर्ज़न के लिए क्या रिज़ॉल्व करता है: सबसे नई रिलीज़, न कि वह टैग जिससे आपने स्क्रिप्ट ली थी। यह पहली बार देखने के लिए ठीक है, लेकिन ऐसे रीबिल्ड के लिए गलत है जिसे आप दोहराना (repeatable) चाहते हैं।

इसलिए किसी भी स्थायी सेटअप के लिए, इंस्टॉलर जो करता है उसे मैन्युअल रूप से करें और सटीक आर्काइव का नाम स्वयं चुनें। यही वह तरीका है जिससे आप बाइनरी को ऐसी जगह रखते हैं जहाँ तक एक सिस्टम सर्विस पहुँच सके, और यह आपको डाउनलोड की गई स्क्रिप्ट को सीधे शेल में पाइप करने से बचाता है।

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 द्वारा पिन किए गए वर्ज़न को प्रिंट करना ही पूरी जाँच है। इंस्टॉलर के तुरंत बाद moli: command not found का मतलब है कि इंस्टॉल डायरेक्टरी आपके PATH में नहीं है, और इंस्टॉलर उस डायरेक्टरी का नाम बताने वाली एक लाइन प्रिंट करता है जिसे आपको जोड़ने की आवश्यकता है।

moli fetch के साथ वन-शॉट एक्सट्रैक्शन

एक एजेंट ब्राउज़र को जो अधिकांश कार्य देता है, वे "इस URL को लोड करें और बताएं कि इसमें क्या है" जैसे होते हैं। इसके लिए किसी सर्वर की आवश्यकता नहीं होती है। moli fetch इंजन को स्टार्ट करता है, एक पेज लोड करता है, एक आर्टिफैक्ट को स्टैंडर्ड आउटपुट पर लिखता है और एग्जिट हो जाता है, इसलिए कॉल्स के बीच मेमोरी में कुछ भी होल्ड नहीं रहता है।

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

पहला कमांड पेज को Markdown के रूप में प्रिंट करता है, जिसकी शुरुआत # Example Domain से होती है। मॉडल को देने के लिए Markdown सबसे सस्ता विकल्प है, क्योंकि यह मार्कअप को हटा देता है और केवल टेक्स्ट रखता है। semantic_tree_text भूमिकाओं (roles) और संरचना को बनाए रखता है, जो कि नेविगेशन-हैवी पेज पर आवश्यक है जहाँ लिंक का महत्व गद्य (prose) जितना ही होता है। --dump json HTTP स्टेटस और रिक्वेस्ट ट्रेस को साथ रखता है, इसलिए जब कोई फेच खाली आए और आपको कारण जानना हो, तो इसका उपयोग करें।

वेट स्ट्रेटेजी यह तय करती है कि आपको कंटेंट मिलेगा या एक खाली शेल। --wait-until networkidle नेटवर्क शांत होने पर वापस आता है। --wait-until domstable तब वापस आता है जब DOM बदलना बंद हो जाता है, जो उन पेजों के लिए बेहतर विकल्प है जो बैकग्राउंड में पोलिंग करते हैं और कभी शांत नहीं होते। --wait-selector आपके द्वारा बताए गए एक सेलेक्टर का इंतजार करता है। यह एकमात्र ऐसी स्ट्रेटेजी है जो आपके द्वारा फेच किए जा रहे पेज के बारे में कुछ जानती है, जो इसे सबसे विश्वसनीय बनाती है जब आप टारगेट के बारे में जानते हों।

स्क्रीनशॉट और PDF के लिए वास्तविक लेआउट की आवश्यकता होती है, और लेआउट डिफ़ॉल्ट रूप से बंद रहता है:

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 डिफ़ॉल्ट लेआउट पॉलिसी को LayoutPolicy::Mock नाम देता है: ज्यामिति (geometry) नकली होती है और कुछ भी पेंट नहीं किया जाता है, क्योंकि लेआउट और पेंट ब्राउज़र का सबसे महंगा हिस्सा हैं। वह डिफ़ॉल्ट ही कारण है कि ऊपर दिए गए मेमोरी आंकड़े ऐसे दिखते हैं। इसका मतलब यह भी है कि खाली PNG आमतौर पर एक टूटे हुए पेज के बजाय एक गायब --layout फ्लैग के कारण होता है।

उन URLs के लिए जिन्हें आपके एजेंट ने खोजा है (न कि आपके द्वारा चुने गए), --block-private-networks जोड़ें। एक एजेंट जो किसी पेज पर पढ़े गए लिंक का अनुसरण करता है, उसे क्लाउड इंस्टेंस क्रेडेंशियल्स के लिए http://169.254.169.254/, या localhost पर किसी डेटाबेस पोर्ट को फेच करने के लिए निर्देशित किया जा सकता है जिसे कभी भी वेब के सामने नहीं आना चाहिए था। वह फ्लैग प्राइवेट एड्रेस स्पेस में नेविगेशन को रोकता है, और --block-cidrs इसे और अधिक सीमित करता है। जब कार्य एक पेज पढ़ने के बजाय क्रॉलिंग का हो, तो उस पाइपलाइन का आकार self-hosted Firecrawl alternatives में कवर किया गया है, और उससे पहले का चरण, यानी URLs खोजना, a SearXNG-backed search skill for agents में कवर किया गया है।

CDP के माध्यम से Moli पर एक एजेंट को पॉइंट करें

ऐसे एजेंट के लिए जो कई चरणों में नेविगेट और क्लिक करता है, इसके बजाय सर्वर चलाएं।

moli serve --host 127.0.0.1 --port 9222

127.0.0.1 और port 9222 डिफ़ॉल्ट हैं, इसलिए एक खाली moli serve पहले से ही केवल loopback पर bind होता है। किसी भी स्थायी कॉन्फ़िगरेशन में दोनों को लिखें, क्योंकि आपके service file को पढ़ने वाले अगले व्यक्ति को यह याद रखने की आवश्यकता नहीं होनी चाहिए कि डिफ़ॉल्ट क्या था।

क्लाइंट को कनेक्ट करने से पहले सर्वर की जाँच करें:

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

एक स्वस्थ सर्वर एक JSON ऑब्जेक्ट के साथ उत्तर देता है जिसमें webSocketDebuggerUrl फ़ील्ड होती है, और वह URL ही है जिससे CDP क्लाइंट जुड़ता है। curl: (7) Failed to connect to 127.0.0.1 port 9222: Connection refused का अर्थ है कि कुछ भी listen नहीं कर रहा है, इसलिए उस टर्मिनल को पढ़ें जिसमें आपने इसे शुरू किया था, या यदि यह एक सर्विस है तो journalctl -u moli -n 50 का उपयोग करें। /json/list खुले targets को सूचीबद्ध करता है और /json/protocol उन domains को सूचीबद्ध करता है जिन्हें यह build लागू करता है, जिससे आपको पता चलता है कि जिस CDP method पर आप निर्भर हैं वह यहाँ मौजूद है या नहीं।

Playwright अपना ब्राउज़र लॉन्च करने के बजाय उस endpoint से जुड़ता है:

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

जो लाइन मायने रखती है वह connectOverCDP है, न कि chromium.launch()। यहाँ कोई child Chromium process नहीं है, इसलिए executablePath और सामान्य container flags जैसे --no-sandbox के पास कार्य करने के लिए कुछ नहीं है। Proxy, cookie और user-agent सेटिंग्स Moli सर्वर पर उसके अपने flags के रूप में जाती हैं, इसी कारण से। पूरे Chrome protocol के बजाय चुनिंदा CDP कवरेज की अपेक्षा करें: एक स्पष्ट unsupported-method error इंजन की सीमा है, आपके कोड में कोई बग नहीं।

दो सर्वर flags यह तय करते हैं कि एजेंट क्या कर सकता है। --layout वास्तविक geometry को चालू करता है, जिसकी आवश्यकता coordinate clicks और screenshots के लिए होती है। --resource वैकल्पिक images, fonts और media को फ़ेच करता है, और यह हर page load पर bandwidth और memory की खपत करता है, इसलिए इसे तब तक बंद रखें जब तक कि पेज यह साबित न कर दे कि उसे इनकी आवश्यकता है। --profile-dir runs के बीच cookies और storage को बनाए रखता है, और इसके बिना हर run डिस्पोजेबल होता है।

ChartOne agent episode, Moli against Chromium, figures published by the Moli project
The data behind this chart
[
  {
    "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
  }
]

प्रोजेक्ट के सैंपल एजेंट वर्कलोड पर, Moli ने Chromium के लिए 169.37 ms की तुलना में 34.85 ms पर CDP कनेक्शन स्वीकार किया, और 348.82 MiB की तुलना में 102.46 MiB के peak PSS (proportional set size, साझा पेजों को साझा करने वाली प्रक्रियाओं के बीच विभाजित करके गिनी गई मेमोरी) पर। संरचनात्मक अंतर अंतिम कॉलम है: 11 के मुकाबले 1 प्रक्रिया। एक प्रक्रिया systemd के पर्यवेक्षण के लिए एक चीज़ है और cap करने के लिए एक cgroup है, जो अगले सेक्शन को छोटा बनाता है।

Run moli serve as a systemd service on loopback

Run the server as a service when an agent needs a browser waiting for it. Keep using moli fetch per URL when it does not, because an idle server still holds its memory.

Do not put port 9222 on a public interface. CDP has no authentication step of any kind. Anyone who can reach that port can drive the browser and read whatever the browser can reach, including any cookies in your profile directory. Keep it on 127.0.0.1. Reach it from another machine through an SSH tunnel (ssh -L 9222:127.0.0.1:9222 user@your-vps) or over a private VPN interface, and let the agent connect to http://127.0.0.1:9222 on its own side of that tunnel.

Create a service user, then the unit file:

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

Write /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 should show active (running), and the curl should return the discovery JSON. ProtectSystem=strict mounts the whole filesystem read-only for this unit, which is why StateDirectory=moli is not optional here: it creates /var/lib/moli, owned by the service user, and makes that one path writable. A unit that starts and then dies with a permission error in journalctl -u moli is nearly always trying to write somewhere ProtectSystem has just made read-only, so move that path under the state directory.

MemoryMax=768M is what makes this safe to run beside your application. The unit gets its own cgroup, and when that cgroup goes over its limit the kernel kills something inside it and leaves the rest of the box alone. The journal records it:

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

Read that line as a sizing signal. Either the pages are heavier than you planned for, or the limit is too low. Set the number from a measurement of your own pages, which is the next section. The same accounting flags fence in any other service on the box, and capping memory and CPU with systemd works through the rest of them.

पीक मेमोरी को स्वयं मापें

प्रकाशित आंकड़े किसी और के हार्डवेयर और किसी और के पेजों से लिए गए हैं। पीक मेमोरी यह तय करती है कि आपका सर्वर सुरक्षित रहेगा या नहीं, और पीक पूरी तरह से इस बात पर निर्भर करता है कि आप क्या लोड करते हैं। साइज तय करने से पहले मापें।

वन-शॉट फेचिंग के लिए, time बाइनरी का उपयोग करें, जो उसी नाम के शेल बिल्टिन की तुलना में कहीं अधिक जानकारी प्रदान करती है:

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

आउटपुट एक रिसोर्स सांख्यिकी ब्लॉक के साथ समाप्त होता है जिसमें Maximum resident set size (kbytes) शामिल है। MiB में बदलने के लिए इसे 1024 से विभाजित करें। इसे उन दस पेजों पर चलाएं जिन्हें आपका एजेंट वास्तव में विजिट करता है, न कि example.com पर, और औसत के बजाय सबसे खराब परिणाम को ध्यान में रखें, क्योंकि OOM killer पीक पर प्रतिक्रिया करता है।

सर्विस के लिए, उस काउंटर को पढ़ें जिसे कर्नेल पहले से ही इसके cgroup के लिए रखता है:

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

memory.peak एक बाइट काउंट है, और यह यूनिट के पिछली बार स्टार्ट होने के बाद का उच्चतम स्तर (high-water mark) है, इसलिए रीस्टार्ट करने पर यह रीसेट हो जाता है। वह आंकड़ा वह है जिससे ऊपर MemoryMax को रहना होगा, जिसमें उस सबसे भारी पेज के लिए भी जगह होनी चाहिए जिसे आपने अभी तक विजिट नहीं किया है। systemd-cgtop -m प्रति यूनिट लाइव उपयोग दिखाता है, जो यह देखने का सबसे तेज़ तरीका है कि आज बॉक्स पर कौन सी सर्विस सबसे अधिक संसाधन ले रही है।

Moli कहाँ विफल होता है, और आपको Chrome की आवश्यकता कब पड़ती है?

यह प्रोजेक्ट 1,308 तुलनीय ब्राउज़र ऑटोमेशन कार्यों का एक बेंचमार्क भी चलाता है और कई इंजनों के लिए स्कोर प्रकाशित करता है।

ChartLexbench headless browser suite, 1,308 tasks, figures published by the Moli project
The data behind this chart
[
  {
    "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 इंजनों में, Moli 0.1.1 ने 81.88 प्रतिशत कार्य पूरे किए और संदर्भ इंजन, Chrome ने 99.85 प्रतिशत कार्य पूरे किए। यह प्रोजेक्ट स्वयं के सूट पर अपना स्कोरिंग कर रहा है, इसलिए इसे एक स्वतंत्र परिणाम के बजाय एक दावे के रूप में पढ़ें।

व्यावहारिक निष्कर्ष सरल है। Moli पर लगभग पाँच में से एक कार्य विफल रहा जिसे Chrome ने पूरा कर लिया। यदि आपका एजेंट आपके द्वारा नियंत्रित पृष्ठों के एक निश्चित सेट पर जाता है, तो वह अनुपात आपको बहुत कम जानकारी देता है, क्योंकि आपके पृष्ठ या तो काम करते हैं या नहीं करते हैं और आप आज दोपहर तक इसका पता लगा सकते हैं। यदि आपका एजेंट ओपन वेब ब्राउज़ करता है, तो यह एक वास्तविक विफलता दर है जिसके अनुसार आपको डिज़ाइन करना होगा।

क्या विफल होता है, यह प्रोजेक्ट के घोषित दायरे से अनुमानित है।

  • वे एप्लिकेशन जो अपने इंटरफ़ेस को DOM के बजाय Canvas एलिमेंट में ड्रा करते हैं, क्योंकि Canvas की स्पष्टता (fidelity) स्पष्ट रूप से दायरे से बाहर है।
  • कुछ भी जिसे WebGL या GPU कंपोजिटिंग की आवश्यकता है, क्योंकि इसमें कोई GPU कंपोजिटर नहीं है।
  • DRM-संरक्षित वीडियो और भारी मीडिया प्लेबैक।
  • विज़ुअल टेस्ट जो Chrome के विरुद्ध पिक्सेल-सटीक स्क्रीनशॉट का दावा करते हैं, क्योंकि Chrome के साथ समानता (parity) कोई लक्ष्य नहीं है।

प्रोजेक्ट द्वारा उद्धृत दूसरा आंकड़ा, 1.612 मिलियन वेब प्लेटफ़ॉर्म टेस्ट पास करने वाला एक पूर्ण रन, मानकों के कवरेज के बारे में एक विवरण है। यह उन साइटों के बारे में कोई वादा नहीं है जिन पर आपका एजेंट जाएगा। एक पृष्ठ केवल अच्छी तरह से समर्थित मानकों का उपयोग कर सकता है और फिर भी बॉट चेक पर विफल हो सकता है, और कोई भी इंजन स्कोर इसे कवर नहीं करता है।

इसलिए डिज़ाइन में फॉलबैक (fallback) बनाए रखें। प्रत्येक URL को पहले Moli पर भेजें। जब कोई पृष्ठ खाली वापस आता है, या कोई सेलेक्टर कभी दिखाई नहीं देता है, तो उस एक URL को Playwright के साथ वास्तविक Chrome का उपयोग करके, किसी बड़ी मशीन पर या ऐसे शेड्यूल पर पुनः प्रयास करें जहाँ 773 MiB की प्रक्रिया वहन योग्य हो। अधिकांश एजेंट अपना अधिकांश समय सामान्य पृष्ठों पर बिताते हैं, इसलिए छोटा इंजन वॉल्यूम संभालता है और महंगा इंजन शेष कार्यभार (tail) संभालता है।

FAQ

क्या Moli मेरे agent के लिए headless Chrome की जगह ले सकता है?

पेज पढ़ने, टेक्स्ट निकालने और सामान्य क्लिकिंग के लिए, आमतौर पर हाँ। 1,308 कार्यों के प्रोजेक्ट के अपने बेंचमार्क पर, इसने Chrome के 99.85 प्रतिशत के मुकाबले 81.88 प्रतिशत कार्य पूरे किए, इसलिए लगभग हर पाँच में से एक कार्य में ऐसी चीज की आवश्यकता होती है जो Moli नहीं करता है। Canvas-rendered applications, WebGL और DRM वीडियो इसकी ज्ञात कमियाँ हैं। उन URLs को वास्तविक Chrome पर भेजें, बजाय इसके कि सब कुछ वापस बदलें।

VPS पर Moli को कितनी RAM की आवश्यकता होती है?

प्रोजेक्ट 192-URL क्रॉल में 73 MiB का median RSS और एक सैंपल एजेंट एपिसोड पर 102.46 MiB का peak PSS रिपोर्ट करता है, जबकि headless Chrome के लिए यह 773 MiB median है। ये उनके पेजों पर दिए गए उनके आँकड़े हैं। वन-शॉट उपयोग के लिए /usr/bin/time -v के साथ moli fetch कॉल के दौरान अपना माप लें, या सर्विस के लिए /sys/fs/cgroup/system.slice/moli.service/memory.peak पढ़ें, फिर MemoryMax को अपने द्वारा देखे गए सबसे खराब आँकड़े से ऊपर सेट करें।

क्या इंटरनेट पर port 9222 को expose करना सुरक्षित है?

नहीं। CDP में कोई authentication नहीं होता है, इसलिए जो कोई भी उस port तक पहुँच सकता है, वह आपके ब्राउज़र को नियंत्रित कर सकता है और ब्राउज़र जो कुछ भी देख सकता है उसे पढ़ सकता है। --host 127.0.0.1 को बनाए रखें, और endpoint तक SSH tunnel या private VPN interface के माध्यम से किसी अन्य मशीन से पहुँचें। यदि आपको किसी अन्य address को bind करना ही है, तो इसे private interface पर रखें और firewall के साथ access को नियंत्रित करें।

मेरा स्क्रीनशॉट खाली क्यों है, या मेरा क्लिक कहीं नहीं लग रहा है?

Layout डिफ़ॉल्ट रूप से बंद होता है। README में डिफ़ॉल्ट पॉलिसी LayoutPolicy::Mock बताई गई है, इसलिए element geometry वास्तविक नहीं होती है और पेज पर किसी बॉक्स पर निर्भर रहने वाली किसी भी चीज़ के पास काम करने के लिए कुछ नहीं होता है। सर्वर को moli serve --layout के साथ शुरू करें, या moli fetch में --layout जोड़ें, और स्क्रीनशॉट तथा coordinate paths काम करने लगेंगे। गायब इमेज एक अलग flag है: --resource।

मुझे Moli का कौन सा version install करना चाहिए?

एक version को पिन करें, और उसे रिकॉर्ड करें। अगस्त 2026 तक वर्तमान release 1.0.1 है, जबकि प्रोजेक्ट द्वारा प्रकाशित बेंचमार्क आँकड़े 0.1.1 पर मापे गए थे, इसलिए जब आप किसी और के साथ नोट्स की तुलना करते हैं तो दोनों एक-दूसरे के स्थान पर उपयोग करने योग्य नहीं हैं। उस tag की moli-x86_64-unknown-linux-gnu.tar.gz डाउनलोड करें और shell installer पर निर्भर रहने के बजाय binary को स्वयं install करें, जो आपके द्वारा fetch किए गए tag के बजाय नवीनतम release को resolve करता है, फिर moli --version के साथ पुष्टि करें।

#headless-browser#ai-agents#moli#rust#scraping#memory