التقط حركة HTTP(S) من تطبيقاتك
A browser, a backend, a TV, a cron job — point it at one address. Same live feed.
# Any client — point it at your per-device PAC URL:
http://<port>.busymate.net/
# Android: Wi-Fi → Proxy → Auto-config → paste the URL
# Desktop: System proxy → Automatic → paste the URL
# Then trust the Busymate CA once, and decrypted traffic
# streams straight into the shared live feed.Charles-style MITM,
نفس المحاكاة والسكربتات ونقاط التوقف ككل مصدر آخر.
رابط PAC واحد، أي عميل
لا حزم SDK ولا عملاء للتثبيت. أي شيء يتحدث إلى وكيل — هاتف أو متصفح أو مهمة cron — يُعد نفسه من رابط إعداد تلقائي واحد ويبدأ البث.
كل جهاز يحتفظ بهويته
كل جهاز يحصل على نطاقه الفرعي ومنفذه، فيبقى مرور فريق بأكمله منسوبًا بدقة جنبًا إلى جنب. لا مزيد من التخمين عمّن تكون تلك الطلبات.
القواعد تعمل على السلك
قواعد الحظر والمحاكاة والإسقاط — ومحرك سكربتات JS المعزول نفسه — تعمل داخل الوكيل نفسه، مطابقة لالتقاط iOS وChrome. مجموعة قواعد واحدة مطبقة أينما تدفق مرورك.
وجّه الخروج إلى أي مكان
سلسل أي جهاز عبر وكيل أمامي أو إقليمي — حسب الدولة أو بمضيف محدد — مباشرة من لوحة التحكم. اختبر السلوك المقيّد جغرافيًا دون مغادرة كرسيك.
يُشغّل بلا SSH
يبلّغ خفي الوكيل عن إصداره وحالته الحية، ويبث سجلاته إلى لوحة التحكم، ويمكن إعادة تشغيله أو تحديثه عن بُعد. قد لا تفتح طرفية على تلك الآلة مجددًا.
Trust once,
A Charles-style MITM that runs as a shared service: one CA, per-host leaves, and rows that land in the same table as every other capture source.
- 01
A CA is born on first run
The proxy generates its own certificate authority the first time it starts — there are no shared keys to pass around. Each device trusts that one certificate once; nothing else on the device changes.
- 02
Per-host leaves, minted on demand
For every intercepted hostname the proxy mints a leaf certificate on the fly — read from the TLS handshake's server name — and handshakes both directions: client to proxy, proxy to origin.
- 03
كل زوج يصل إلى الخلاصة المشتركة
يظهر كل زوج طلب/استجابة تم فك تشفيره في خلاصة لوحة التحكم لحظة اكتماله — بالشكل نفسه الذي تنتجه التقاطات iOS وAndroid، فتجمع خلاصة واحدة كل المصادر، ولا تؤدي إعادة المحاولة أبدًا إلى تكرار أي إدخال.
- 04
The dashboard steers it live
Breakpoint continues, request resends, device renames and settings pushes arrive over Realtime channels the proxy subscribes to — applied in-process, no restart, no SSH session.
The proxy,
Everything a client or a script needs is served by the proxy itself — autoconfig, the CA bundle, and a per-device port pool.
- Proxy + management
- :8888 (HTTP proxy + management API)
- TLS interception
- SNI listener :8443 · per-host leaf certificates
- Per-device ports
- :9000–19999 pool · <port>.busymate.net
- PAC autoconfig
- / · /proxy.pac · /wpad.dat (same PAC body at all three)
- CA distribution
- Certificate bundle served by the proxy itself; the CA is generated on first run
- Ingest
- تتدفق الالتقاطات إلى الخلاصة لحظة حدوثها — بلا طوابير ولا ملفات دفعات، ولا تؤدي إعادة المحاولة أبدًا إلى تكرار أي إدخال
- Remote control
- Realtime channels for breakpoints, resends and settings; live build/status reporting and remote restart from the dashboard
Proxy questions,
Which clients can I point at the proxy?
Anything that can use an HTTP proxy or a PAC URL: Android phones, desktop browsers, smart TVs, your own backends, cron jobs, debug builds. If it has proxy settings, it can stream into the feed.
Do I have to trust a certificate on every device?
Once per device. The proxy has a single CA (generated on its first run); every per-host leaf certificate chains to it, so one trust step covers every host you later decrypt.
What happens to hosts I don't want decrypted?
They pass through encrypted, untouched. Decryption is scoped by the same dashboard-managed SSL host lists that drive iOS and Android capture — one rule set for every source.
Why does each device get its own port and subdomain?
Each allocated device gets a dedicated port from the pool and a matching hostname, so a whole team's traffic stays exactly attributed in the shared feed — no guessing whose requests those are.
هل أحتاج إلى حسابي الخاص لوكيل عكسي لتوجيه مخرج جهاز؟
لا — اختر بلدًا وسيختار Busymate تلقائيًا وكيلًا سليمًا من المجموعة المدمجة. يمكنك أيضًا استخدام مضيفك ومنفذك الخاصين إن فضّلت ذلك.
إذا تحققت من عناوين IP لخروج جهاز ما، فهل أرى ما يراه الموقع الهدف؟
لا — تلك القائمة هي عناوين IP القبول التي يقبل وكيلنا الاتصالات منها لذلك الجهاز، وليست المصدر الظاهر للوجهة. الوكيل الخارجي (العكسي) هو ما تراه الوجهة فعليًا.
وكلاء مدمجون،
وجّه جهازًا عبر وكيل عكسي (upstream) من مجموعة مدمجة افتراضيًا، أو عبر مضيفك الخاص — واعرف بالضبط أي عنوان IP هو أيهما.
- 01
وكلاء حقيقيون، جاهزون افتراضيًا
يمكن لكل جهاز التوجيه فورًا عبر مجموعة من الوكلاء العكسيين المُعرَّفين مسبقًا — اختر واحدًا حسب البلد (أو زوّده بمضيف صريح) وستخرج حركة المرور فعليًا عبره. لا حاجة إلى إعداد حساب منفصل مسبقًا.
- 02
كتابة واحدة توجّه مخرج جهاز
اختر تلقائيًا وكيلًا سليمًا حسب البلد، أو زوّده بمضيف ومنفذ صريحين. يلتقط كل من proxy-server وموصل CDP هذا الإعداد تلقائيًا عبر اشتراكهما في الإعدادات — دون إعادة تشغيل ودون إعادة نشر.
- 03
عنوان IP القبول ≠ ما تراه الوجهة
العناوين المدرجة في حالة خروج جهاز ما هي عناوين IP مصدر CONNECT التي يقبلها وكيلنا من ذلك الجهاز — وليست عنوان IP الذي يراه الخادم الهدف. ذلك المصدر الظاهر للهدف يُحدَّده بالكامل الوكيل الخارجي الذي وجّهت الحركة عبره.
- 04
بيانات الاعتماد لا تصل إلى أي عملية قراءة أبدًا
تُكتب معلومات المستخدم وكلمة المرور للوكيل العكسي مرة واحدة، ثم تُزال من كل عملية قراءة لاحقة — سواء كان جلب إعدادات، أو دمج إعدادات فعّالة، أو استدعاء أداة من قِبل وكيل ذكاء اصطناعي، فكلها ترى علامة hasCredentials محجوبة فقط، لا القيمة أبدًا.
Connect a device in
خذ رابط PAC الخاص بك، وثق بشهادة CA مرة واحدة، وشاهد الحركة المفكوكة تصل إلى الخلاصة.