Explore the Core Capabilities of Aegis

Aegis is a personal digital firewall ruleset based on Surge.

It helps users accurately identify and classify traffic locally on iOS and macOS, then define traffic policies according to their own needs.

Aegis is not traditional protection software, and it does not automatically make security decisions for you.

It is a ruleset for identifying and presenting network communication behavior.

In real use, Aegis identifies and classifies network communication.

It helps you understand more clearly how different applications and services communicate.

A rule match only means that a communication has been identified. It describes the type and behavior characteristics of the communication, but it does not itself make a risk judgment.

Based on this visible information, users can define corresponding traffic policies according to their own usage scenarios and needs.

This process is not complicated and does not depend on frequent adjustment. Instead, through long-term use, it gradually establishes a stable and sustainable way of judgment.

On this basis, the Aegis ruleset can also be used as a basis for traffic routing.

By identifying and classifying different communication behaviors, users can route traffic to different policies, nodes, or handling methods instead of being limited to simple allow or block decisions.

Designed Specifically for Surge and Fully Compatible with iOS and macOS

From the beginning, Aegis was built around the rule system and runtime mechanism of Surge. Its rule structure, matching logic, and module separation are designed around real behavior in iOS and macOS environments.

Aegis is not a general-purpose ruleset and does not pursue compatibility across proxy platforms. The project focuses on the Apple ecosystem and is designed around the Surge rule system, using iOS and macOS as the primary runtime environments to keep rule behavior clear, controllable, and aligned with real usage scenarios.

Suitable for Policy Routing, Communication Identification, and Security-assisted Configuration

Aegis rules are not used only to “block” or “allow” communication. They are built around the foundational capability of communication identification. By labeling traffic sources, protocol characteristics, and behavior patterns, users can use this information as a basis for later policy configuration.

In real use, Aegis can serve multiple scenarios at the same time:

For example, it can be used as a preliminary judgment condition for traffic routing, as an observation basis for security policy adjustment, or simply to understand the communication structure of applications and services. Different users can apply rule results to different levels of policy decisions according to their own needs, without being forced into a single usage model.

Rules Are Maintained in Plaintext with Clear Structure, Complete Comments, and Auditability

All Aegis rules are maintained in plaintext and include clear module separation and comments. This design is not meant to “show complexity”; it is meant to ensure that the rules themselves can be read, understood, and reviewed.

Every rule should have a traceable reason for existing, and its scope and decision logic should be clear. By keeping rule structure clear and comments consistent, users can independently examine whether a rule is reasonable and decide whether to enable, modify, or replace it without relying solely on the author’s judgment.

Configurations Are Self-hosted Through This Repository and Do Not Depend on Third-party Rule Sources

Aegis rules and configuration files are maintained and distributed through the project repository and do not depend on external third-party rule sources. This design reduces uncertainty in the rule supply path and avoids unexpected behavior caused by external changes.

For users, this means the rule source is clear, the update path is explicit, and every change can be traced through version history. This self-hosted approach does not pursue update frequency for its own sake; it emphasizes transparency and controllability in the rule maintenance process.

Users Can Freely Combine and Deploy Rule Policies According to Their Own Needs

Aegis does not require users to enable every rule module at once. Instead, the ruleset is divided into relatively independent modules, allowing users to choose and combine them based on their network environment, usage scenario, and risk preference.

This modular design allows the ruleset to evolve gradually as user understanding improves, rather than introducing excessive complexity at the beginning. Users can observe first, then adjust, then converge on a stable policy that fits their needs.

Project Commits Use GPG Signatures to Verify Rule and Configuration Integrity

To ensure the integrity and trustworthiness of rules and configuration files, the Aegis project uses GPG signatures for commits. Each formal commit can be verified for source and integrity, reducing the risk of tampering during transmission or distribution.

This mechanism does not directly improve rule “effectiveness”, but it provides a basic trust guarantee for rule maintenance, allowing users to know where the rules they use come from and whether they remain in their original state.

Follows Technical Neutrality, Information Transparency, and Independence Without Commercial Capital Influence

From the beginning, Aegis has clearly insisted on technical neutrality, information transparency, and independence. This means the ruleset itself does not assume how the network “should” be used and does not attach value judgments to communication behavior. It focuses on presenting facts.

At the level of rule maintenance and project governance, Aegis does not accept commercial capital involvement and does not use any commercial goal as a design premise. All rule choices, module divisions, and policy boundaries are built around explainability, auditability, and long-term maintainability.

This independence ensures that the ruleset will not favor specific services, platforms, or usage patterns because of commercial demands. Users can always make their own judgments and control their own network traffic based on clear and complete information.

This Project Contains No Proxy Recommendations, Traffic Hijacking, Monitoring Mechanisms, or Hidden Behavior

Aegis explicitly contains no proxy node recommendations, traffic hijacking logic, or hidden monitoring mechanisms. Rules operate only at the communication identification and policy matching layer. They do not parse or store actual data content.

This clear boundary helps users understand the capability scope of Aegis during use and avoids unnecessary misunderstandings or excessive expectations about the ruleset.

Who Aegis Is For

Aegis is not for everyone, but it has unique value for users who care about understanding network behavior and maintaining independent control. Aegis is likely suitable for you if you:

• Want to understand the traffic structure and behavior types on your device instead of blindly allowing or blocking
• Want to build more granular traffic policies that better fit your own scenarios
• Value rule transparency, auditability, and sustainable maintenance
• Want to avoid black-box judgments and make decisions based on rules and facts

For users who only want a smooth default internet experience, Aegis will not break normal network access. But using Aegis more deeply can help you better understand the details of network communication.

What You Can Do Next

After reading this article, you can continue exploring according to your own goals:

• Read How to Use the Aegis Ruleset to learn practical usage
• Watch the iOS video tutorials and macOS video tutorials for a deeper understanding
• Review the complete rules and module documentation on GitHub

With these resources, you can move from theoretical understanding to practical use and define policies on your own devices that better fit your usage scenarios.