OmniRoute/docs/i18n/ka/docs/frameworks/TRAFFIC_INSPECTOR.md

Traffic Inspector (ქართული)

🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇬🇷 el · 🇪🇸 es · 🇪🇪 et · 🇮🇷 fa · 🇫🇮 fi · 🇫🇷 fr · 🇮🇪 ga · 🇮🇳 gu · 🇳🇬 ha · 🇮🇱 he · 🇮🇳 hi · 🇭🇷 hr · 🇭🇺 hu · 🇦🇲 hy · 🇮🇩 id · 🇳🇬 ig · 🇮🇹 it · 🇯🇵 ja · 🇰🇭 km · 🇮🇳 kn · 🇰🇷 ko · 🇱🇹 lt · 🇱🇻 lv · 🇮🇳 ml · 🇮🇳 mr · 🇲🇾 ms · 🇲🇹 mt · 🇲🇲 my · 🇳🇵 ne · 🇳🇱 nl · 🇳🇴 no · 🇮🇳 or · 🇮🇳 pa · 🇵🇭 phi · 🇵🇱 pl · 🇵🇹 pt · 🇧🇷 pt-BR · 🇷🇴 ro · 🇷🇺 ru · 🇱🇰 si · 🇸🇰 sk · 🇸🇮 sl · 🇷🇸 sr · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇵🇰 ur · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW

---

Traffic Inspector არის OmniRoute-ის ჩაშენებული HTTPS ტრაფიკის გამმართველი — Charles Proxy / mitmweb / HTTP Toolkit-ის მსგავსი ინსტრუმენტი, რომელიც აცნობიერებს LLM-ებს და აგენტებს. ის განთავსებულია მისამართზე /dashboard/tools/traffic-inspector და პირდაპირ რეჟიმში იღებს ტრაფიკს ერთდროულად მაქსიმუმ 5 აღბეჭდვის წყაროდან.

მართვის პანელის მდებარეობა: /dashboard/tools/traffic-inspector გვერდითი ზოლის ჯგუფი: ინსტრუმენტები (AgentBridge-ის შემდეგ) აგრეთვე იხილეთ: AGENTBRIDGE.md — AgentBridge არის აღბეჭდვის რეჟიმი 1.

---

§1 მიმოხილვა

რა გამოარჩევს Traffic Inspector-ს

ფუნქცია	mitmweb	Charles	Fiddler	OmniRoute Traffic Inspector
ვებზე დაფუძნებული	✓	✗	✗	✓
ღია კოდის მქონე	✓	✗	ნაწილობრივ	✓
აგენტების ამომცნობი (იცის, მოთხოვნა Antigravity-დან/Copilot-იდან/და სხვ. არის თუ არა)	✗	✗	✗	✓
LLM-ების ამომცნობი (აანალიზებს OpenAI/Anthropic/Gemini-ის სტრუქტურას, ტოკენებსა და მოდელს)	✗	✗	✗	✓
მოდელების შესაბამისობის ხილვადობა (gemini-3-flash → claude-sonnet-4.7)	✗	✗	✗	✓
პროქსისა და ზემდგომი სერვერის დაყოვნების განცალკევება	ნაწილობრივ	✗	✗	✓
OmniRoute-თან ინტეგრირებული მარშრუტიზაცია, სარეზერვო გადართვა და ღირებულება	✗	✗	✗	✓
სისტემის მასშტაბის პროქსის გამართვა (კომპიუტერზე არსებული ნებისმიერი აპლიკაცია)	✓	✓	✓	✓
მორგებული ჰოსტის აღბეჭდვა (DNS-ის გადამისამართება თითოეული ჰოსტისთვის)	✓	✓	✓	✓
HTTP_PROXY გარემოს რეჟიმი	✓	✓	✓	✓
საუბრის ხედი (მრავალეტაპიანი ბუშტები, tool_use/tool_result)	✗	✗	✗	✓
SSE ნაკადის გამაერთიანებელი (აღდგენა delta მოვლენებიდან)	✗	✗	✗	✓
სესიის ჩაწერა (სახელდებული, ექსპორტირებადი .har/.jsonl)	✗	✓	✓	✓

არქიტექტურა ერთ აბზაცში

TrafficBuffer (src/mitm/inspector/buffer.ts) არის საერთო, მეხსიერებაში განთავსებული რგოლური ბუფერი (ნაგულისხმევად 1000 ჩანაწერი, კონფიგურირებადი INSPECTOR_BUFFER_SIZE-ის მეშვეობით). აღბეჭდვის ყველა წყარო მასში წერს push()-ის მეშვეობით. ბუფერი თითოეულ ჩანაწერს kindDetector.ts-ის გამოყენებით ახარისხებს (განსაზღვრავს, არის თუ არა ეს LLM მოთხოვნა), გამოთვლის contextKey-ს (სისტემური მოთხოვნის SHA-256 ანაბეჭდი) და globalTrafficBuffer.subscribe()-ის მეშვეობით გადასცემს ყველა WebSocket გამომწერს. მართვის პანელი უკავშირდება GET /api/tools/traffic-inspector/ws-ის მეშვეობით და დაკავშირებისას იღებს სნეპშოტს, შემდეგ კი — new/update/clear მოვლენებს.

---

§2 ჩაჭერის რეჟიმები

Traffic Inspector მხარს უჭერს 5 ერთდროულ ჩაჭერის წყაროს. თითოეული მათგანის ჩართვა და გამორთვა დამოუკიდებლადაა შესაძლებელი. ყოველ InterceptedRequest-ში (src/mitm/inspector/types.ts) არსებული source ველი ერთ-ერთია შემდეგთაგან: "agent-bridge", "custom-host", "http-proxy", "system-proxy" ან "tproxy".

რეჟიმი 1 — AgentBridge (ნაგულისხმევი, ყოველთვის ჩართული)

წყარო: AgentBridge-ის დამმუშავებლები (src/mitm/handlers/base.ts) მექანიზმი: MitmHandlerBase-ში intercept()-ის ყოველი გამოძახება გადამისამართებამდე იძახებს hookBufferStart()-ს, ხოლო დასრულებისას — hookBufferUpdate()-ს. დამატებითი კონფიგურაცია არ არის საჭირო — მუშაობას AgentBridge-ის გაშვებისთანავე იწყებს. წვდომის არეალი: AgentBridge-ში კონფიგურირებული 9 IDE აგენტი შენიშვნა: InterceptedRequest-ში source ველი = "agent-bridge"

რეჟიმი 2 — მორგებული ჰოსტები (DNS გადამისამართება)

წყარო: მომხმარებლის მიერ განსაზღვრული ჰოსტების სია (inspector_custom_hosts ცხრილი) მექანიზმი: UI-დან ჰოსტის დამატებისას /etc/hosts-ში ემატება 127.0.0.1 <host> (საჭიროებს sudo-ს). არსებული AgentBridge MITM სერვერი (პორტი 443) ახალი ჰოსტისთვის დინამიკურად ქმნის SNI სერტიფიკატს. წვდომის არეალი: ნებისმიერი აპლიკაცია, რომელიც დამატებულ ჰოსტს იყენებს — აპლიკაციის კონფიგურაციის შეცვლა საჭირო არ არის შენიშვნა: source = "custom-host"

გამოყენების მაგალითები:

• Python სკრიპტებიდან api.openai.com-ის მონიტორინგი
• my-internal-llm.company.com-ის გამართვა
• იმავე ქსელში არსებული მობილური მოწყობილობებიდან ტრაფიკის ჩაჭერა (ARP spoofing-ის მეშვეობით — გაფართოებული რეჟიმი)

რეჟიმი 3 — HTTP_PROXY მსმენელი (პორტი 8080)

წყარო: აპლიკაციები, რომლებიც იყენებენ HTTP_PROXY/HTTPS_PROXY გარემოს ცვლადებს მექანიზმი: მეორეული მსმენელი პორტზე 8080 (src/mitm/inspector/httpProxyServer.ts), რომელიც მუშაობს როგორც სტანდარტული ცხადად მითითებული HTTP/HTTPS პროქსი. იღებს CONNECT გვირაბებს (HTTPS) და პირდაპირ HTTP მოთხოვნებს. წვდომის არეალი: ნებისმიერი აპლიკაცია, რომელიც ითვალისწინებს HTTP_PROXY გარემოს ცვლადს — DNS-ის შეცვლა და sudo საჭირო არ არის შენიშვნა: source = "http-proxy"

# ერთი ბრძანებისთვის სწრაფი ჩაჭერა:
HTTPS_PROXY=http://127.0.0.1:8080 curl https://api.openai.com/v1/models

# მუდმივი ჩაჭერა shell-ის სესიის განმავლობაში:
export HTTP_PROXY=http://127.0.0.1:8080
export HTTPS_PROXY=http://127.0.0.1:8080

TLS-ის შეზღუდვა: HTTPS CONNECT გვირაბებიდან ნაგულისხმევად მხოლოდ მეტამონაცემები იჭრება (ჰოსტი, პორტი, დროითი მაჩვენებლები) — TLS-ის შიგთავსი არ იშიფრება. შიგთავსის სრულად შესამოწმებლად ჩართეთ „პროქსი-რეჟიმში HTTPS-ის გაშიფვრა“ გადამრთველი (საჭიროებს ხელით ჩართვას და AgentBridge-ის სერტიფიკატი სანდოდ უნდა იყოს მიჩნეული).

პორტის კონფლიქტი: თუ პორტი 8080 უკვე გამოიყენება, AgentBridge აბრუნებს 409 პასუხს სტრუქტურირებული შეცდომით. შეცვალეთ პორტი INSPECTOR_HTTP_PROXY_PORT გარემოს ცვლადის მეშვეობით.

რეჟიმი 4 — სისტემური პროქსი (გაფართოებული, ხელით ჩასართავი)

წყარო: ოპერაციული სისტემის დონის პროქსის პარამეტრები (ვრცელდება კომპიუტერზე არსებულ ყველა აპლიკაციაზე) მექანიზმი: იყენებს ოპერაციული სისტემის API-ებს მთელი HTTP/HTTPS ტრაფიკის HTTP_PROXY მსმენელის გავლით გადასამისამართებლად:

• macOS: networksetup -setwebproxy / -setsecurewebproxy
• Linux: gsettings set org.gnome.system.proxy + /etc/environment
• Windows: netsh winhttp set proxy 127.0.0.1:8080 წვდომის არეალი: კომპიუტერზე არსებული ყველა აპლიკაცია, რომელიც ითვალისწინებს სისტემური პროქსის პარამეტრებს შენიშვნა: source = "system-proxy"

უსაფრთხოების მექანიზმები:

• ავტომატური გამორთვის ტაიმერი (ნაგულისხმევად 30 წუთი; კონფიგურირდება INSPECTOR_SYSTEM_PROXY_GUARD_MINUTES-ის მეშვეობით)
• სისტემური პროქსის წინა მდგომარეობა ინახება DB-ში და გაუქმებისას აღდგება
• თუ მომხმარებელი აქტიური რეჟიმის დროს გვერდიდან გადავა, მართვის პანელი აჩვენებს მოთხოვნას „სისტემური პროქსის დაბრუნება“
• UI აჩვენებს ⚠ გაფართოებული ნიშნულს და ცხადი დადასტურების მოსანიშნ ველს

რეჟიმი 5 — TPROXY გამჭვირვალე გაშიფვრა (Linux, root, ხელით ჩასართავი)

წყარო: ბირთვის TPROXY + პოლიტიკაზე დაფუძნებული მარშრუტიზაცია (src/mitm/tproxy/) მექანიზმი: mangle OUTPUT-ში ნიშნავს სამიზნე პორტზე (ნაგულისხმევად 443) მიმართულ ახალ ლოკალურ გამავალ TCP კავშირებს, ip rule მონიშნულ პაკეტებს ლოკალურ მიწოდებაზე გადაამისამართებს, ხოლო mangle PREROUTING-ის TPROXY სამიზნე მათ გამჭვირვალე (IP_TRANSPARENT) მსმენელს გადასცემს (ნაგულისხმევი პორტი 8443). მსმენელი TLS-ს ასრულებს დინამიკური CA-ის მიერ ყოველი SNI ჰოსტის სახელისთვის მოთხოვნისას გაცემული საბოლოო სერტიფიკატით, იჭერს გაშიფრულ მიმოცვლას და მოთხოვნას თავდაპირველ დანიშნულებამდე ხელახლა დაშიფრული სახით აგზავნის. წვდომის არეალი: სამიზნე პორტზე არსებული ნებისმიერი დანიშნულების ჰოსტები — /etc/hosts-ის გაყალბება, HTTP_PROXY გარემოს ცვლადი ან სისტემური პროქსის ცვლილება საჭირო არ არის. ჩაჭერილი პროცესის კონფიგურაციის შეცვლა საჭირო არ არის, თუმცა ის დინამიკურ CA-ს უნდა ენდობოდეს. შენიშვნა: source = "tproxy"

მოთხოვნები: მხოლოდ Linux (IP_TRANSPARENT მხოლოდ Linux-ზეა ხელმისაწვდომი), CAP_NET_ADMIN შესაძლებლობა (root) და მშობლიური N-API დამატება, რომელიც C ინსტრუმენტთა ჯაჭვით უნდა აიგოს (npm run build:native:tproxy). როდესაც ეს პირობები მიუწვდომელია, მართვის პანელზე გადამრთველი გათიშულია და მინიშნებად აჩვენებს ტექსტს „TPROXY გაშიფვრა საჭიროებს Linux-ს + root-ს + მშობლიურ დამატებას“. firewall-ის წესები ტრანზაქციულად გამოიყენება და უქმდება (ავარიული გათიშვის შემდეგ mangle წესი არასოდეს რჩება) და ხელახლა ჩატვირთვისას იწმინდება. SO_MARK-ზე დაფუძნებული ციკლის საწინააღმდეგო მექანიზმი ხელს უშლის პროქსის მიერ ხელახლა დაშიფრული გადამისამართების ხელმეორედ ჩაჭერას.

ეს მნიშვნელოვანი ქვესისტემაა, რომელსაც ოპერატორის ცალკე სახელმძღვანელო აქვს — firewall-ის სრული რეცეპტის, თითოეულ SNI-ზე დინამიკური CA-ის + ნდობის საცავის ინსტალატორის, მხოლოდ ლოკალური მარშრუტის, ციკლის საწინააღმდეგო დეტალებისა და კონფიგურაციის სქემის სანახავად იხილეთ docs/security/MITM-TPROXY-DECRYPT.md (git-ში; /docs-ში არ კომპილირდება). გადამრთველი იმართება GET / POST / DELETE /api/tools/agent-bridge/tproxy-ის მეშვეობით (შენიშვნა: მარშრუტი AgentBridge-ის პრეფიქსის ქვეშაა და არა Traffic Inspector-ის პრეფიქსის ქვეშ).

ჩაჭერის რეჟიმების შედარება

რეჟიმი	დაყენება	Sudo?	წვდომის არეალი	შენიშვნები
1. AgentBridge	ავტომატური	ერთხელ (სერტიფიკატი+hosts)	9 IDE აგენტი	ნაგულისხმევად ჩართულია
2. მორგებული Hosts	თითოეული ჰოსტისთვის შეყვანა	დიახ (hosts ფაილი)	ნებისმიერი აპი, რომელიც ამ ჰოსტს იყენებს	შენახულია DB-ში
3. HTTP_PROXY	export HTTPS_PROXY=...	არა	აპები, რომლებიც გარემოს ცვლადებს ითვალისწინებენ	პორტი 8080; ნაგულისხმევად TLS გაშიფვრის გარეშე
4. სისტემის მასშტაბით	გადამრთველი + დადასტურება	დიახ	მოწყობილობაზე არსებული ყველა აპი	ავტომატურად გაითიშება 30 წუთში
5. TPROXY გაშიფვრა	გადამრთველი (Linux + ნატიური დამატება)	დიახ (root + CA ინსტალაცია)	ნებისმიერი ჰოსტი სამიზნე პორტზე	შიფრავს ნებისმიერ ჰოსტს; ნაგულისხმევად გამორთულია — იხილეთ docs/security/MITM-TPROXY-DECRYPT.md (git; არ კომპილირდება /docs-ში)

---

§3 UI

3.1 განლაგება

┌─ ტრაფიკის ინსპექტორი ─────────────────────────────────────────────────┐
│ ┌─ გადაღების წყაროების ხელსაწყოთა ზოლი ────────────────────────────┐   │
│ │ [✓ AgentBridge]  [✓ მორგებული ჰოსტები (3)]  [○ HTTP_PROXY]  [○ სისტემა]│   │
│ └─────────────────────────────────────────────────────────────────────┘  │
│ ┌─ ფილტრების/მართვის ზოლი ─────────────────────────────────────────┐   │
│ │ პროფილი: (●) მხოლოდ LLM  (○) მორგებული  (○) ყველა                  │   │
│ │ [⎉ პაუზა] [🗑 გასუფთავება] [⬇ .har] [● სესიის ჩაწერა] ● პირდაპირ 482/1k│   │
│ └─────────────────────────────────────────────────────────────────────┘  │
├══◀▶══════════════════════════════╬══════════════════════════════════════╤╡
│ მოთხოვნების სია (ზომაცვლადი)     ║ დეტალების პანელი                    ▲ │
│ ────────────────────────────── │ ║ [საუბარი][სათაურები][მოთხოვნა]      │ │
│ ▎ 14:32 POST 200 12k AG openai ║ [პასუხი][დრო][LLM][სტატისტიკა]      │ │
│ ▎ 14:31 POST 200 8k  CP openai ║                                     ▼ │
│ ▎ 14:31 POST 503 ⚠   KR ...   ║                                       │
│ ▎ 14:30 GET  200 3k  🌐 მორგებული ║                                     │
└══════════════════════════════════╝══════════════════════════════════════╝

3.2 მოთხოვნების სია (მარცხენა პანელი)

• ვირტუალიზებული (useVirtualList + ResizeObserver): გაჭედვის გარეშე ამუშავებს 1000 ელემენტს
• ავტომატური გადახვევა დათვალიერებისას შეჩერების გადამრთველით
• სტატუსების ფერადი კოდირება: მწვანე (2xx), ყვითელი (3xx), წითელი (4xx/5xx), ნაცრისფერი (მიმდინარე)
• აგენტის ემოჯი: 🔵 Antigravity, 🟢 Copilot, 🟠 Kiro, 🟣 Codex, 🔷 Cursor, 🟤 Zed, 🟡 Claude Code, ⚫ Open Code, 🌐 მორგებული ჰოსტი
• კონტექსტის ფერადი ზოლი: 1px-იანი მარცხენა საზღვარი, რომლის ფერი განისაზღვრება contextKey-ით (სისტემური პრომპტის SHA-256) — ვიზუალურად აჯგუფებს დაკავშირებულ საუბრებს
• ტანის ზარმაცი ჩატვირთვა: დეტალების ჩანართებში მატერიალიზდება მხოლოდ არჩეული მოთხოვნის ტანი (თავიდან იცილებს 1000 × 1MB ზომის ტანის რენდერინგს)

3.3 დეტალების პანელი — 7 ჩანართი

ჩანართი	შიგთავსი	შენიშვნები
საუბარი	მრავალსვლიანი საუბრის ბუშტები (system/user/assistant + tool_use/tool_result)	ნორმალიზებულია ნებისმიერი პროვაიდერის ფორმატიდან; ნაჩვენებია მხოლოდ მაშინ, როცა detectedKind === "llm"
სათაურები	მოთხოვნისა და პასუხის სათაურების ცხრილები	სენსიტიური სათაურები (Authorization, Cookie, api-key) ნაგულისხმევად შენიღბულია; გადამრთველი „საიდუმლოებების ჩვენება“
მოთხოვნა	დაუმუშავებელი ტანი, JSON-ის ხისებრი ხედი, მოდელის ველის ნიშანი	ლამაზად დაფორმატებული JSON ან დაუმუშავებელი ტექსტი
პასუხი	დაუმუშავებელი ტანი ან SSE მოვლენების სია; გადამრთველი „დაუმუშავებელი ↔ გაერთიანებული“	SSE გამაერთიანებელი delta მოვლენებიდან საბოლოო შეტყობინებას აღადგენს
დრო	კასკადური დიაგრამა: პროქსის ზედნადები ხარჯი და ზედა დონის სერვერის დაყოვნება	სრული დრო, TTFB და ზომა
LLM-ის დეტალები	პროვაიდერი, მოდელი, შეტყობინებების რაოდენობა, შემავალი/გამავალი ტოკენები, ღირებულების შეფასება, ასახული სამიზნე	ნაჩვენებია მხოლოდ LLM მოთხოვნებისთვის
სტატისტიკა	Recharts: დაყოვნების დროითი დიაგრამა, ტოკენების სვეტოვანი დიაგრამა, ხელსაწყოს გამოძახებების წერტილოვანი დიაგრამა	ნაჩვენებია მხოლოდ ჩაწერილი სესიის ჩატვირთვისას

3.4 ხელსაწყოთა ზოლის მართვის ელემენტები

მართვის ელემენტი	მოქმედება
⎉ პაუზა	აჩერებს ახალი მოთხოვნების რენდერინგს; გროვდება ნიშანი „X ახალი“
🗑 გასუფთავება	ასუფთავებს UI-ის სიას (სერვერის ბუფერზე არ მოქმედებს)
⬇ .har-ის ექსპორტი	მიმდინარე გაფილტრულ სიას HAR ფაილად ჩამოტვირთავს
● სესიის ჩაწერა	იწყებს დასახელებული სესიის ჩაწერას
პროფილის ამრჩევი	მხოლოდ LLM / მორგებული ჰოსტები / ყველა
ჰოსტის ფილტრი	host ველში ქვესტრიქონის დამთხვევა
აგენტის ფილტრი	ჩამოსაშლელი სია: ყველა / თითოეული აგენტი
სტატუსის ფილტრი	ყველა / 2xx / 3xx / 4xx / 5xx / შეცდომა
წყაროს ფილტრი	ყველა / agent-bridge / custom-host / http-proxy / system-proxy / tproxy
პირდაპირი ფილტრი	მხოლოდ მიმდინარე (ღია) მოთხოვნების ჩვენება — liveOnly გადამრთველი (იხილეთ §4.6)

3.5 ზომაცვლადი პანელები

• სია და დეტალების პანელი ერთმანეთისგან გადაადგილებადი სახელურითაა გამოყოფილი
• სიის სიგანე: მინ. 280px, მაქს. 720px, ინახება localStorage-ში (inspector.listWidth)
• შესაძლებელია 48px-იან ზოლამდე ჩაკეცვა (მხოლოდ ხატულები); გასაშლელად დააწკაპუნეთ ზოლში არსებულ მწკრივზე

---

§4 LLM-ის გათვალისწინებით შექმნილი ფუნქციები

4.1 ტიპის დეტექტორი (src/mitm/inspector/kindDetector.ts)

თითოეულ მოთხოვნას 4 სიგნალის გამოყენებით ანიჭებს კლასიფიკაციას: "llm", "app" ან "unknown":

1. ჰოსტების რეესტრი — LLM API-ის დაახლოებით 18 ცნობილი ჰოსტის სახელი (OpenAI, Anthropic, Gemini, Groq, Mistral, Together, Fireworks, Cohere, Perplexity, Hugging Face, OpenRouter, xAI, Moonshot და სხვ.)
2. ბილიკის შაბლონები — /v1/chat/completions, /v1/messages, /generateContent, /v1/responses და სხვ.
3. სხეულის სტრუქტურა — ამოიცნობს ველებს: messages[] (OpenAI/Claude), contents[] (Gemini), prompt, input
4. User-agent-ის მინიშნებები — UA სტრიქონში codex, claude, gemini, antigravity, kiro, copilot, cursor

Mode 2-ის საშუალებით დამატებული მორგებული ჰოსტები საკუთარ kind-ს ფორმის შეყვანილი მონაცემებიდან იღებენ (ნაგულისხმევი მნიშვნელობაა "custom").

4.2 SSE-ის გამაერთიანებელი (src/mitm/inspector/sseMerger.ts)

დამოუკიდებელი clean-room იმპლემენტაცია. მოვლენების დამუშავება მიჰყვება WHATWG-ის სერვერის მიერ გაგზავნილი მოვლენების ალგორითმს, ხოლო რეკონსტრუქცია — OpenAI-ის, Anthropic-ისა და Gemini-ის საჯარო სტრიმინგის სქემებს.

დაუმუშავებელი SSE დელტა-მოვლენებიდან აღადგენს ასისტენტის საბოლოო შეტყობინებას:

• Anthropic: ინდექსის მიხედვით აგროვებს content_block_delta-ს; ამუშავებს text_delta-ს, input_json_delta-სა (ინსტრუმენტების გამოძახებები) და thinking_delta-ს
• OpenAI: ინდექსის მიხედვით აგროვებს Chat Completions-ის არჩევანებს/ინსტრუმენტების გამოძახებებს და Responses API-ის გამომავალ ელემენტებს
• Gemini: აგროვებს candidates[i].content.parts-ს
• Unknown: დაუმუშავებელ მოვლენებს უცვლელად აბრუნებს

Response ჩანართში ნაჩვენებია გადამრთველი: "დაუმუშავებელი მოვლენები ↔ გაერთიანებული".

4.3 საუბრის ნორმალიზატორი (src/mitm/inspector/conversationNormalizer.ts)

დამოუკიდებელი clean-room იმპლემენტაცია. ნორმალიზაცია განსაზღვრულია ლოკალური შავი ყუთის კონტრაქტებითა და OpenAI-ის, Anthropic-ისა და Gemini-ის შეტყობინებების საჯარო სქემებით; აღმავალი იმპლემენტაციის საწყისი კოდი გამოყენებული არ არის.

რენდერინგამდე OpenAI-ის, Anthropic-ისა და Gemini-ის შეტყობინებების ფორმატებს ერთიან NormalizedConversation-ად გარდაქმნის:

interface NormalizedConversation {
  request: NormalizedTurn[]; // შეტყობინებები / შიგთავსები / მოთხოვნის სხეულიდან მიღებული prompt
  response: NormalizedTurn[]; // ასისტენტის პასუხი (გაერთიანებული sseMerger-ის მეშვეობით)
  contextKey: string | null; // სისტემური prompt-ის SHA-256 ანაბეჭდი
}

ბლოკების ტიპები: text, tool_use, tool_result. Conversation ჩანართი პროვაიდერის მიუხედავად ამ სტრუქტურას იყენებს.

4.4 კონტექსტის გასაღების გაფერადება (src/mitm/inspector/contextKey.ts)

• ითვლის სისტემური prompt-ის SHA-256-ს (პირველი role:system შეტყობინება, ან system ველი, ან Gemini-ის systemInstruction)
• აბრუნებს 12-სიმბოლოიან თექვსმეტობით პრეფიქსს ("a3f9c2...")
• ფრონტენდი გასაღებს მარცხენა საზღვრის ზოლისთვის განსაზღვრულ HSL ფერს უსაბამებს
• ფილტრი „იგივე კონტექსტი“: ctx #a3f ჩიპზე დაწკაპუნება ამატებს ფილტრს, რათა მხოლოდ იმავე ანაბეჭდის მქონე მოთხოვნები გამოჩნდეს

ეს ამარტივებს ერთსა და იმავე აგენტის სესიაში გაშვებული სხვადასხვა „პერსონის“ ან დავალების ვიზუალურად გარჩევას.

4.5 LLM-ის მეტამონაცემების ამოღება

LLM მოთხოვნებისთვის LLM Details ჩანართი ამოიღებს:

interface LlmMetadata {
  provider: string | null; // "openai" | "anthropic" | "gemini" | ...
  apiKind: string | null; // "chat.completions" | "messages" | "embeddings" | ...
  model: string | null; // მოთხოვნის სხეულიდან ან პასუხიდან
  messages: number; // მონაცვლეობების რაოდენობა
  tokensIn: number | null; // usage.prompt_tokens / usage.input_tokens
  tokensOut: number | null; // usage.completion_tokens / usage.output_tokens
  streamed: boolean; // true, თუ პასუხი SSE-ია
  mappedTo: string | null; // x-omniroute-mapped სათაური
  costEstimateUsd: number | null; // OmniRoute-ის ფასების საფუძველზე შეფასებული ღირებულება
}

4.6 შესრულების პროცესში მყოფი მოთხოვნების ცოცხალი ფილტრი

მოთხოვნის status ველია number | "in-flight" | "error" — მოთხოვნის დაწყებისთანავე ჩანაწერი ემატება როგორც "in-flight" და პასუხის (ან შეცდომის) მიღებისას ადგილზევე განახლდება. ხელსაწყოთა ზოლის "Live" გადამრთველი (liveOnly, i18n გასაღები trafficInspector.liveOnly) სიას ზღუდავს იმ ჩანაწერებით, რომელთა status === "in-flight", რაც ღია კავშირების რეალურ დროში დაკვირვების საშუალებას გაძლევთ.

ფილტრი არის სუფთა, კლიენტის მხარეს არსებული პრედიკატი ფაილში src/lib/inspector/matchesTrafficFilter.ts:

if (f.liveOnly && req.status !== "in-flight") return false;

გადამრთველის მდგომარეობა ინახება useTrafficFilters-ში (ინსპექტორის მართვის პანელის ჰუკები) და სხვა ფილტრებთან (პროფილი, ჰოსტი, აგენტი, წყარო, სტატუსი, კონტექსტი) კომბინირდება.

4.7 პროცესის მიკუთვნება (Linux)

Linux-ზე თითოეული გადაჭერილი მოთხოვნა შეიძლება მიეკუთვნოს მის წარმომქმნელ ლოკალურ პროცესს. InterceptedRequest-ს ემატება ორი არასავალდებულო ველი:

pid?: number;          // წარმომქმნელი პროცესის id (მხოლოდ Linux)
processName?: string;  // წარმომქმნელი პროცესის სახელი (მხოლოდ Linux)

src/mitm/inspector/processAttribution.ts კავშირის კლიენტის ეფემერულ პორტს PID-სა და სახელს შემდეგნაირად უსაბამებს:

1. კითხულობს /proc/net/tcp-სა და /proc/net/tcp6-ს, რათა პორტისთვის სოკეტის inode იპოვოს (parseProcNetTcpForInode, სუფთა პარსერი, რომლის ტესტირებაც fixture-ებითაა შესაძლებელი).
2. /proc/<pid>/fd/-ში ეძებს სიმბოლურ ბმულს socket:[<inode>]-ზე.
3. პროცესის სახელს /proc/<pid>/comm-იდან კითხულობს.

1-წამიანი TTL კეში დატვირთვისას procfs-ის სკანირების ხარჯს ზღუდავს. მიკუთვნება მაქსიმალური მცდელობის პრინციპით მუშაობს — ნებისმიერი წარუმატებლობა null-ით სრულდება და ჩაჭერას არასოდეს ბლოკავს. macOS/Windows-ზე ფუნქცია null-ს აბრუნებს (stub; lsof/GetExtendedTcpTable-ის მხარდაჭერა შემდგომი სამუშაოა).

---

§5 სესიები

5.1 სესიის ჩაწერა

1. ხელსაწყოთა ზოლში დააწკაპუნეთ "● სესიის ჩაწერა" → შეიყვანეთ სახელი (არასავალდებულო)
2. პირდაპირი ნაკადი ჩვეულებრივ გრძელდება; წითელი, პულსირებადი ინდიკატორი აჩვენებს ◉ REC · <სახელი> · 00:42 · 23 მოთხოვნა
3. დააწკაპუნეთ "⏹ შეჩერება" → სესიის ანაბეჭდი შეინახება inspector_sessions + inspector_session_requests-ში

5.2 ჩაწერილი სესიის ნახვა

ხელსაწყოთა ზოლში არსებული სესიები ჩამოსაშლელი მენიუ შენახულ სესიებს აჩვენებს. ერთ-ერთის არჩევისას:

• იტვირთება სესიის ანაბეჭდი (გაყინული მდგომარეობა)
• ბანერზე გამოჩნდება: ჩაწერილი სესიის "<სახელი>" ნახვა — [პირდაპირ რეჟიმში დაბრუნება]
• ხელმისაწვდომი ხდება სტატისტიკის ჩანართი Recharts-ის აგრეგირებული მონაცემებით

5.3 ექსპორტის ფორმატები

თითოეული სესიის ექსპორტი შესაძლებელია შემდეგ ფორმატებში:

ფორმატი	გამოყენება
HAR (HTTP Archive 1.2)	თავსებადია Chrome DevTools-თან, Charles-თან და Fiddler-თან — იმპორტი ავტონომიური ანალიზისთვის
JSONL	თითო InterceptedRequest თითოეულ სტრიქონზე — თავსებადია llm-interceptor ფორმატთან

ექსპორტი შესაძლებელია GET /api/tools/traffic-inspector/sessions/{id}/export.har-ის ან სესიების ჩამოსაშლელ მენიუში არსებული ⬇ ღილაკის მეშვეობით.

---

§6 უსაფრთხოება

Traffic Inspector აჩვენებს მთელ გადაჭერილ HTTPS ტრაფიკს, ავტორიზაციის სათაურებისა და მოთხოვნის სხეულების ჩათვლით. დანერგილია შემდეგი კონტროლის მექანიზმები:

კონტროლის მექანიზმი	დეტალები
LOCAL_ONLY	ყველა მარშრუტი და WebSocket-ის საბოლოო წერტილი მხოლოდ loopback-იდანაა ხელმისაწვდომი (ავტორიზაციამდე აღსრულდება routeGuard.ts-ში)
საიდუმლო მონაცემების შენიღბვა	წრფივი maskSecret() სკანერი RFC 6750 Bearer ავტორიზაციის მონაცემებს, პროვაიდერის პრეფიქსიან გასაღებებსა და გრძელ გაუმჭვირვალე ტოკენებს TrafficBuffer.push()-მდე ფარავს
სხეულის ზომის ზღვარი	INSPECTOR_MAX_BODY_KB-ზე (ნაგულისხმევად 1024 KB) დიდი სხეულები იკვეცება შეტყობინებით "(წარმადობისთვის შეკვეცილია)"
სათაურების გასუფთავება	სახელები ქვედა რეგისტრში გადადის; კადრირების/hop-by-hop და პროქსის ავტორიზაციის სათაურები იშლება; cookie-ები სრულად იფარება; ავტორიზაციის მონაცემების მნიშვნელობები გადაეცემა maskSecret()-ს
CSP	მკაცრი Content Security Policy Traffic Inspector-ის გვერდებზე, ჩასმული პასუხის სხეულების მეშვეობით XSS-ის თავიდან ასაცილებლად
ნაგულისხმევად მუდმივი შენახვის გარეშე	TrafficBuffer მეხსიერებაში ინახება და სერვერის გადატვირთვისას იკარგება. სესიები მუდმივად მხოლოდ აშკარად ჩაწერის შემთხვევაში ინახება

გამოყენებული მკაცრი წესები

წესი	გამოყენება
#12 sanitizeErrorMessage	Traffic Inspector-ის მარშრუტებიდან დაბრუნებული ყველა HTTP შეცდომის პასუხი გასუფთავებულია
#15 + #17 isLocalOnlyPath()	/api/tools/traffic-inspector/ არის LOCAL_ONLY + SPAWN_CAPABLE (სისტემური პროქსის ბრძანებები)

ცნობილი შეზღუდვები

• სისტემის მასშტაბის პროქსის რეჟიმი გავლენას ახდენს მოწყობილობაზე არსებულ ყველა აპლიკაციაზე, მათ შორის VPN კლიენტებსა და SSO-ზე. ყოველთვის გამოიყენეთ ავტომატური გამორთვის ტაიმერთან ერთად. არ გამოიყენოთ საზიარო მოწყობილობებზე.
• CONNECT გვირაბის HTTPS: რეჟიმი 3 (HTTP_PROXY) HTTPS დანიშნულების წერტილებისთვის მხოლოდ გვირაბის მეტამონაცემებს აფიქსირებს, თუ TLS გადაჭერა ჩართული არ არის. ეს განზრახაა — გამჭვირვალე გადაჭერა იმ აპლიკაციებში TLS შემოწმებას დაარღვევდა, თუ AgentBridge-ის სერტიფიკატი სანდოდ არ იქნებოდა მიჩნეული.
• ზოგიერთ კომპონენტში პირდაპირ ჩაშენებული სტრიქონები: ზოგიერთ UI კომპონენტს (F7/F8) აქვს მცირე რაოდენობის პირდაპირ ჩაშენებული სტრიქონები, რომლებიც ჯერ არ არის დაფარული i18n გასაღებებით. ისინი i18n-ის ხარვეზების ანგარიშში დოკუმენტირებულია, როგორც ცნობილი შეზღუდვა; მათი მიგრაცია მომდევნო ეტაპზე მოხდება. აღნიშნული სტრიქონები UI-ის დეკორატიული წარწერებია, რომელთა თარგმნაც ფუნქციური გამოყენებისთვის საჭირო არ არის.

---

§7 პრობლემების მოგვარება

WebSocket-ის კავშირის გაწყვეტა

თუ პირდაპირ ნაკადში გამოჩნდება „კავშირი გაწყვეტილია“:

1. შეამოწმეთ, სერვერი კვლავ მუშაობს თუ არა: GET /api/tools/traffic-inspector/capture-modes
2. ხელახლა ჩატვირთეთ გვერდი — WebSocket კვლავ დაუკავშირდება და ახალ სურათს მიიღებს
3. თუ სერვერი გადაიტვირთა, მეხსიერებაში არსებული ბუფერი გასუფთავდა — ძველი ჩანაწერები დაკარგულია, თუ სესია არ იყო ჩაწერილი

კონფლიქტი 8080 პორტზე

თუ HTTP_PROXY რეჟიმი ვერ გაეშვა:

lsof -i :8080    # პროცესის პოვნა

შეცვალეთ პორტი:

# .env
INSPECTOR_HTTP_PROXY_PORT=8888

სისტემური პროქსი საწყის მდგომარეობაში არ დაბრუნდა

თუ OmniRoute ავარიულად გაითიშა მაშინ, როდესაც სისტემური პროქსის რეჟიმი აქტიურია:

macOS:

networksetup -setwebproxystate Wi-Fi off
networksetup -setsecurewebproxystate Wi-Fi off

Linux (GNOME):

gsettings set org.gnome.system.proxy mode 'none'

Windows:

netsh winhttp reset proxy

თუ მონაცემთა ბაზის მდგომარეობა მიუთითებს, რომ პროქსი აქტიური იყო, შემდეგი ჩატვირთვისას მართვის პანელი ასევე შემოგთავაზებთ „სისტემური პროქსის საწყის მდგომარეობაში დაბრუნებას“.

ბუფერი სავსეა

როდესაც ბუფერი მიაღწევს INSPECTOR_BUFFER_SIZE-ს (ნაგულისხმევად 1000), ახალი ჩანაწერები ყველაზე ძველ ჩანაწერებს ჩაანაცვლებს. თუ მნიშვნელოვანი მოთხოვნები იკარგება:

• გაზარდეთ INSPECTOR_BUFFER_SIZE (მაგ., 5000) — მეხსიერების მეტი მოხმარების სანაცვლოდ ჩანაწერები უფრო დიდხანს შეინახება
• შესაბამისი დროის მონაკვეთის მონაცემთა ბაზაში შესანახად ჩაწერეთ სესია

---

§8 API-ს ცნობარი

ყველა მარშრუტი არის LOCAL_ONLY (მხოლოდ უკუკავშირის ინტერფეისისთვის) და SPAWN_CAPABLE (სისტემური პროქსის ბრძანებები). იხილეთ src/server/authz/routeGuard.ts.

საბაზისო მისამართი: /api/tools/traffic-inspector/

მოთხოვნების მართვა

მეთოდი	მისამართი	აღწერა
GET	/requests	მოთხოვნების სია (გაფილტვრადი: ?profile=llm&host=&agent=&status=&source=&sessionId=)
GET	/requests/{id}	ერთი მოთხოვნის დეტალები
DELETE	/requests	მეხსიერებაში არსებული ბუფერის გასუფთავება
POST	/requests/{id}/replay	იმავე მოთხოვნის ხელახლა შესრულება OmniRoute-ის როუტერის გავლით
PUT	/requests/{id}/annotation	მოთხოვნაზე შენიშვნის შენახვა ან განახლება

WebSocket

მეთოდი	მისამართი	აღწერა
GET	/ws	WebSocket-ის პირდაპირი ნაკადი. დაკავშირებისას აგზავნის snapshot-ს, შემდეგ კი new/update/clear მოვლენებს

ექსპორტი

მეთოდი	მისამართი	აღწერა
GET	/export.har	მიმდინარე გაფილტრული სიის HAR 1.2-ად ექსპორტირება

მორგებული ჰოსტები

მეთოდი	მისამართი	აღწერა
GET	/hosts	მორგებული ჰოსტების სია
POST	/hosts	ჰოსტის დამატება (/etc/hosts ავტომატურად რედაქტირდება)
DELETE	/hosts/{host}	ჰოსტის წაშლა
PATCH	/hosts/{host}	enabled მდგომარეობის გადართვა

ჩაჭერის რეჟიმები

მეთოდი	მისამართი	აღწერა
GET	/capture-modes	AgentBridge-ის / მორგებული ჰოსტების / HTTP_PROXY-ის / სისტემური პროქსის რეჟიმების მდგომარეობა + tls-intercept გადამრთველი
POST	/capture-modes/http-proxy	HTTP_PROXY მსმენელის გაშვება/შეჩერება ({action: "start"|"stop"})
POST	/capture-modes/system-proxy	სისტემური პროქსის გამოყენება/საწყის მდგომარეობაში დაბრუნება ({action: "apply"|"revert"})
POST	/capture-modes/tls-intercept	პროქსის რეჟიმში HTTPS სხეულის გაშიფვრის გადართვა ({enabled: boolean})

TPROXY-ის გაშიფვრას (ჩაჭერის რეჟიმი 5) მართავს ცალკე მარშრუტი AgentBridge-ის პრეფიქსის ქვეშ — GET / POST / DELETE /api/tools/agent-bridge/tproxy — და არა /api/tools/traffic-inspector/-ის ქვეშ. იხილეთ docs/security/MITM-TPROXY-DECRYPT.md (git-ში; /docs-ში არ კომპილირდება).

სესიები

მეთოდი	მისამართი	აღწერა
POST	/sessions	ჩაწერის დაწყება ({name?: string})
PATCH	/sessions/{id}	შეჩერება ან სახელის გადარქმევა ({action: "stop"|"rename", name?: string})
GET	/sessions	ყველა შენახული სესიის სია
GET	/sessions/{id}	სესიის სურათი (ყველა მოთხოვნა)
DELETE	/sessions/{id}	სესიის წაშლა
GET	/sessions/{id}/export.har	სესიის HAR 1.2-ად ექსპორტირება

შიდა მიღება (D4-ის სარეზერვო მექანიზმი)

მეთოდი	მისამართი	აღწერა
POST	/internal/ingest	იღებს server.cjs-ის გამჭოლი მარშრუტიდან ჩაჭერილ მოთხოვნას; საჭიროებს INSPECTOR_INTERNAL_INGEST_TOKEN სათაურს

OpenAPI-ის სრული სქემები: docs/openapi.yaml → ტეგი Traffic Inspector.