在不同分析阶段之间保留上下文，而不是把每个数据包当成孤立事件。
网络安全 · 协议分析 · 流量取证 · 自动化
一个统一的技术工作空间。从原始流量开始，走向可执行的技术洞察。
Arenyxa 是一个模块化网络安全与协议分析平台，面向网络抓包、协议检查、MITM 测试、API 分析、流量取证、自动化与高权限运维工作流。它的目标是减少抓包工具、调试代理、安全分析工具与自动化流程之间的割裂。
使用可视化工作空间进行调查，同时通过命令行执行可重复、可验证的操作。
将体验模式、导航策略与高权限授权拆分为不同的安全边界。
01
平台概览
Arenyxa 被设计成一个技术平台，而不是单一用途的代理工具或抓包查看器。
传统网络分析往往需要在抓包工具、HTTP 代理、临时脚本、API 客户端、浏览器开发者工具和独立自动化系统之间来回切换。Arenyxa 的目标是在保持各引擎模块化的同时，把这些工作流整合到统一的技术操作模型中。
可观测性
理解真正经过网络链路的数据。
抓取流量、识别会话、解析协议行为，并保留后续调查需要的证据与上下文。
拦截
在授权条件下检查应用行为。
通过受控拦截完成调试、请求分析、协议检查与 MITM 测试。
运维
把一次性分析转化为可重复流程。
扩展到健康检查、自动化、压力测试、恢复与运行验证。
02
设计原则
模块化、权限边界分离与运行韧性，是 Arenyxa 的核心工程约束。
界面模式不能等同于权限。
体验模式只负责改变界面与工作流呈现；高风险能力仍由身份、策略、完整性与授权检查独立控制。
核心引擎应保持可独立测试。
抓包、MITM、协议分析、存储、安全、恢复和自动化可以独立演进，而不是被迫捆绑成难维护的单体。
优先采用有界并发。
性能优化必须可测量、可恢复、可预测，避免通过盲目增加 worker 数量换取短期吞吐。
完整性与恢复属于生产能力。
健康诊断、清单校验、修复路径、审计与故障处理属于平台架构，而不是发布之后的补丁。
03
核心能力
独立引擎通过共享分析工作流连接起来。
平台围绕真实的网络调查生命周期组织：获取流量、理解协议、检查应用行为、关联证据、自动化可重复操作，并围绕高权限行为维持清晰的控制边界。
01
流量获取
Network Capture
围绕会话和工作流进行流量捕获与检查，支持过滤、流关联、证据保留以及后续协议分析。
PCAP流会话证据
02
受控拦截
MITM Engine
用于授权环境下的应用层流量拦截、调试与协议检查，覆盖 TLS、HTTP/2、WebSocket 和 GraphQL 等分析场景。
TLS 1.3HTTP/2WebSocketGraphQL
03
协议智能
Protocol Intelligence
把原始传输与应用流量转化为更高层的结构化理解，强调解码、流关联、行为上下文与异常调查线索。
解码关联分析调查
04
应用与 API 分析
API & Application Analysis
把 REST、GraphQL、HAR 和请求/响应分析放回网络上下文中，支持重放与差异对比。
RESTGraphQLHAR重放
05
自动化
Automation
把手工分析、健康检查、压力测试与修复流程转化为可重复、有边界、可验证的操作。
任务健康压力修复
06
高权限工作空间
Developer / Enterprise / Root
不同运行上下文可展示不同工作空间，但真正权限继续由独立身份、策略与 Root 完整性路径控制。
身份策略RootEnterprise
04
协议支持面
协议能力围绕流量类型与调查目标组织，而不是只堆砌协议名称。
分析面示例分析目标
传输与 TLS
TCP · TLS 1.3
连接上下文、加密状态与传输行为
Web 协议
HTTP/1.x · HTTP/2 · WebSocket
请求/响应、流与长连接会话
API 协议
REST · GraphQL
结构化服务通信与应用语义
分析工件
PCAP · HAR
导入、导出、保留与跨工具证据工作流
工程说明
协议支持应以平台能否可靠解析、关联并呈现有意义的信息来衡量，而不是简单统计协议名称数量。
05
典型工作流
围绕端到端调查流程组织，而不是一组互不相关的小工具。
流量取证
抓取 → 过滤 → 关联 → 保留
获取流量、降低噪音、关联相关活动，并保存后续技术分析所需的证据。
应用调试
拦截 → 检查 → 重放 → 对比
在授权测试条件下检查应用行为，并对请求与响应变化进行对比。
协议调查
解码 → 映射 → 关联 → 解释
从底层传输细节逐步建立对协议行为与会话语义的理解。
运行验证
检查 → 压力测试 → 修复 → 验证
检查健康状态、施加有界压力、修复已知状态，并验证恢复是否真正成功。
06
架构设计
呈现、导航、身份与高权限授权被刻意分离。
选择一个工作空间本身不能授予权限。界面可以投影模式与工作区，而安全敏感操作仍由独立的身份、策略与完整性检查控制。
身份
→ExperienceContext
→Experience Mode
→Workspace
→导航策略
→动态侧边栏
→页面注册表
表现层
页面、导航、体验投影与面向用户的技术工作空间。
应用层
工作流编排、数据包分析、运行操作与服务协调。
引擎层
抓包、MITM、协议智能、自动化、Crawler 与分析引擎。
安全与授权层
身份、开发者访问、企业控制、Root 权限、零信任策略与完整性执行。
运行时与持久化层
存储、调度、韧性、诊断、恢复与执行环境。
07
体验与角色
不同技术上下文可以呈现不同工作空间，同时保持授权边界独立。
聚焦核心能力
以更简洁方式访问核心分析流程。
高级分析
面向需要深入抓包、协议与应用分析的技术用户。
工程工作空间
提供终端、插件/沙箱、工程诊断与开发者工作流。
企业运行上下文
以身份与策略组织受管理的企业级工作空间。
最高技术权限
只有通过安全关键的 Root 身份认证与完整性检查后才能获得相应权限；仅切换界面模式绝不能授予 Root 权限。
08
安全模型
安全敏感行为围绕可验证身份、策略与完整性设计。
◇
零信任策略
高风险策略决策应明确、可验证，并在关键路径上默认拒绝。
◎
硬件支持的设备身份
在支持设备上，通过 TPM 相关能力增强本地设备身份与信任边界。
⌁
Root 权限分离
Root 能力依赖 Root 身份认证与完整性验证，而不是许可证或界面模式。
⟐
企业身份控制
企业上下文由身份、Enrollment、策略与本地管理边界共同治理。
◫
审计能力
高权限操作、恢复动作和关键状态变化应留下足够证据供审阅。
↺
恢复完整性
修复流程不仅要复制文件，还必须验证恢复后的状态。
09
运行与运维
同一平台可承载桌面分析、服务协调与分布式执行角色。
交互式分析
主要 GUI 与开发者工作流，用于本地抓包、调试、检查与调查。
协调服务
面向集中式工作流、服务协调与运行管理。
分布式执行
用于有界后台执行、任务分发与工作负载隔离。
运行关注点设计响应
并发自适应 / 有界执行，而不是无限制创建 worker
故障诊断、受控恢复与明确错误面
高权限执行安全敏感操作前执行授权与完整性检查
10
数据与韧性
本地优先的持久化模型，同时保留向高并发部署扩展的路径。
SQLite
默认本地存储
适合桌面端与本地优先工作流。
PostgreSQL
高并发扩展路径
适合更重并发、协调与多进程/多机器运行模型。
Health · Manifest · Repair
运行韧性
健康检查、完整性清单和修复流程共同构成运行安全模型。
11
命令行工作流
CLI 被当作一等操作界面，而不是 GUI 的附属功能。
arenyxa · developer terminal
$ arenyxa test-all
运行完整验证与质量门。$ arenyxa stress-test --profile standard
验证有界并发与运行韧性。$ arenyxa health-check
检查运行时、依赖、存储与安全状态。$ arenyxa repair
执行受控修复并验证恢复状态。12
质量工程
发布可信度来自可重复质量门，而不是只靠人工点测。
自动化验证
架构契约、运行边界、并发行为与韧性应持续可测试。
压力条件验证
通过 Quick / Standard / Extreme 等配置暴露竞争、饥饿与资源边界问题。
源码与修复校验
清单与恢复资产必须可验证，避免修复过程引入不可信状态。
持续集成
发布候选在进入分发前应保持自动化流水线全绿。
13
典型应用场景
面向开发者、安全工程师、协议研究人员与技术运维人员。
调查可疑应用流量
抓取、过滤、关联协议行为并保留证据。
调试复杂服务通信
检查请求响应、GraphQL、WebSocket 与可重放工件。
理解复杂或未文档化行为
从数据包和字节逐步建立协议级解释。
验证运行健康与可恢复性
执行健康、压力、完整性与修复流程。
GUI 与终端并行工作
在可视化调查与命令驱动操作之间切换。
区分体验与权限
呈现合适工作空间，同时继续执行身份、策略与权限边界。
14
工程边界
专业工具应明确它优化什么，也应明确哪些边界不能被模糊。
拦截、调试与安全测试应仅用于操作者有权分析的系统与流量。
体验模式、导航可见性和许可证不能替代 Root 身份认证、完整性或企业策略。
更高吞吐不能以无控制并发、饥饿或不可恢复运行状态为代价。
修复只有在恢复状态被验证后才算完成，而不是文件复制结束就算成功。
15
引擎深度解析
引擎级职责与边界。
只有当每个引擎都承担清晰职责时，Arenyxa 才能保持可维护性。Capture 获取流量；Protocol Intelligence 解释流量；Security 授权操作；Recovery 验证恢复后的状态。
Capture Engine
负责数据包获取、会话构建、过滤输入、抓包生命周期以及面向证据的交接。它应独立于 UI 导航和高层授权策略。
- 数据包 / 流获取
- 会话上下文
- 抓包生命周期
- 证据交接
MITM Engine
负责受控拦截、具备 TLS 上下文的应用检查、流生命周期，以及授权环境中的请求/响应操作。
- TLS 协商上下文
- HTTP 检查
- WebSocket 流
- 面向重放的状态
Protocol Intelligence
把数据包和流转换为语义结构、关联关系和调查线索。输出应解释行为，而不只是暴露原始字段。
- 解码
- 流关联
- 协议语义
- 异常线索
Automation Engine
以明确的取消机制、有界并发、故障传播和可验证的完成条件执行可重复流程。
- 任务编排
- 批量执行
- 超时
- 验证
Security Kernel
独立于功能所在工作空间做出安全敏感决策。导航可见性绝不能替代真实权限。
- 身份
- 策略
- 完整性
- 权限
Recovery & Health
检测降级状态、验证清单、恢复可信资产，并在宣布恢复完成前验证修复后的行为。
- 健康检查
- 修复清单
- 完整性验证
- 恢复验证
16
企业模型
Enterprise 是一种运行上下文，而不是权限绕过机制。
Enterprise 功能应通过身份、Enrollment、管理和策略进行投影。界面可以展示企业工具，但受保护操作仍取决于底层权限模型。
Enterprise Identity
将组织感知的身份与 Enrollment 状态与视觉模式选择分离表示。
Local Super Admin
提供受管理的本地管理能力，但不会取代 Root Developer 的技术最高权限。
Identity Vault
本地加密身份状态可保存 Enrollment、管理元数据以及权限关系。
Enrollment Code
受控 Enrollment 支持显式加入流程，而不是静默信任外部 Enterprise 上下文。
Pending Enrollment Queue
未批准的 Enrollment 请求保持待处理状态，直到获授权的管理员作出决定。
17
Root Developer
最高技术权限，同时保留不可绕过的安全检查。
Root Developer 面向深度工程、调试与恢复。当 Root 会话有效且身份认证/完整性检查通过后，产品许可、Experience Mode 和角色呈现都不应阻止技术能力访问；但 Root 身份认证与完整性检查本身仍然是强制的。
设备 / Root 密钥→身份认证→完整性验证→已验证的 Root 会话→完整技术权限
Root 权限 ≠ UI 选择
选择 Root 工作空间只是请求一种呈现状态，并不会创建权限。
产品门槛不能高于 Root
在安全关键检查通过后，许可和 Experience Gate 不应向 Root Developer 隐藏技术功能。
完整性始终强制
Root Developer 不得绕过用于建立 Root 会话真实性的检查。
Developer Authority Utility
离线密钥签发、续期、撤销和备份流程应让私有权限材料始终保留在本地。
18
性能与并发
性能是一个受控的系统工程问题。
Arenyxa 偏好自适应并发、有界队列、明确的超时边界和可观测运行状态。稳定吞吐比创建最多 worker 更重要。
关注点故障模式工程响应
主机并发饥饿按主机协调并限制等待者行为
后台执行任务无限增长worker 限制、取消和生命周期归属
网络操作无限期停滞明确 DNS / TCP / TLS / connect 超时边界
存储锁竞争默认使用本地 SQLite；更高并发走 PostgreSQL 路径
压力验证错误信心可重复的 Quick / Standard / Extreme 配置
19
发布工程
发布就绪是一条证据链。
生成可执行文件并不等于发布成功。源码完整性、测试结果、打包行为、运行时冒烟检查、修复资产以及 CI 都必须对同一个发布候选达成一致。
源码清单→单元与契约测试→压力验证→构建→打包→安装→冒烟测试→CI 全绿
SOURCE_MANIFEST.sha256
为发布源码提供可复现的完整性参考。
Repair manifest & seed
恢复资产应与预期的可信基线一致并保持可验证。
质量门
架构、安全、运行时、性能和打包门槛可以减少单一测试造成的盲区。
GitHub Actions
只要必需的 CI 任务仍是红色，发布候选就不应被视为完成。
20
平台方向
先确保 Windows 稳定，再扩大平台范围。
当前工程方向优先打造稳定、完整的 Windows 产品，然后再扩大平台矩阵。这样可以在架构、安全和运行时边界仍快速演进时，让验证保持聚焦。
Windows 为主要目标
桌面 UI、抓包、MITM、Developer Mode、Enterprise 工作流、打包和恢复首先在 Windows 上验证。
Linux 在稳定之后跟进
跨平台扩展应在核心契约足够成熟之后进行，避免在不同平台重复尚未解决的缺陷。
CLI 始终是一等能力
平台扩展不应让 GUI 成为唯一操作界面；直接终端工作流仍是产品架构的一部分。
模块化增长
新能力应通过稳定的引擎和契约集成，而不是在没有必要时替换已经成熟的子系统。
Arenyxa
把网络分析从碎片化工具链，收敛成统一技术工作流。
旗舰站用于产品展示与下载；本页用于系统性介绍 Arenyxa 的能力、架构、安全模型与工程原则。