This repository is a third-party research and maintenance workspace for text-based network routing configuration design. It studies how routing policies, compatibility layers, migration paths, documentation, and small operational helpers can be organized and maintained over time.
Some artifacts in this repository are compatible with Surge. That compatibility does not make this project a Surge tool, plugin, service, official resource, or affiliated ecosystem component. Surge compatibility is a technical fact about certain files here, not the identity of the repository itself.
The repository currently contains three main asset types:
- routing configuration artifacts and mainline-specific modules under
neorulset26/ - operational reference utilities under
tools/ - research, migration, and responsibility documentation under
docs/
This project publishes text-based configuration artifacts, documentation, and reference implementations. It does not provide, operate, broker, or distribute proxy servers, VPN services, transport capacity, managed access services, or account resources.
- This repository is an independent third-party project and has no affiliation with Nssurge Inc. or any other trademark holder referenced in the documentation.
- Surge compatibility is described only for interoperability. This repository is not a Surge product, official extension, support channel, or bundled utility.
- Users are solely responsible for ensuring that any review, adaptation, deployment, import, or use of repository contents complies with applicable law, regulatory requirements, platform terms, internal security policy, and contractual obligations in their jurisdiction.
- See
docs/legal/LEGAL.mdfor the full legal boundary statement, trademark acknowledgments, compliance notice, and liability disclaimer.
The repository should be read as a configuration research project, not as a finished access product.
Its main focus is:
- routing policy structure and classification
- configuration naming and maintenance strategy
- migration planning for published configuration paths
- compatibility-oriented module organization
- operational support tooling that helps validate or sustain configuration workflows
Its main purpose is not:
- providing network access services
- guaranteeing reachability of any third-party platform
- recommending regulatory bypass behavior
- functioning as an official tool for any commercial software product
neorulset26/: the active configuration mainline and supporting referencesneorulset26/modules/: platform-specific modules released with the active configuration mainlinetools/: reference operational utilities and self-hosted support componentsdocs/: legal, development, migration, and repository documentation
Current top-level layout:
/
├── neorulset26/ # active rules and mainline-specific modules
├── tools/ # reference operational helpers
└── docs/ # legal and project documentation
The repository root is intentionally kept as an entry surface. Project policy, legal boundaries, and long-form references should live under docs/ rather than accumulating as loose root documents.
This repository is organized around a few long-term research questions:
- How should routing configuration files be split, named, and layered for maintenance?
- How should compatibility-specific modules be separated from the main configuration line?
- How should migration be handled when historical paths and newer structures coexist?
- How should small operational helpers support a configuration project without turning the repository into a hosted service?
The maintained text artifacts are outputs of that work. They are not presented as guarantees of suitability, legality, security posture, or service access outcome in any given environment.
If you are trying to understand the project, start with the design and structure documents before looking at specific configuration files.
- Architecture reference:
neorulset26/ENGINEERING_GUIDE.md - Configuration URL reference:
neorulset26/RULESET_URLS.md - Migration-oriented path list:
neorulset26/MIGRATION_RULE_URLS.md - Repository layout notes:
docs/development/repository-layout.md - Collaboration notes:
docs/development/collaboration-guide.md - Legal boundary statement:
docs/legal/LEGAL.md - Usage and safety notice:
docs/guides/usage-and-safety.md - Mainline compatibility modules:
neorulset26/modules/README.md - Tools overview:
tools/README.md
Context For Existing Users
- The former
archive/legacy/transition surface has been fully removed. - Map any retired path to its current equivalent via
neorulset26/MIGRATION_RULE_URLS.mdand switch downstream consumers toneorulset26/RULESET_URLS.md. - Requests against old
archive/legacy/...paths will return 404 and will not be restored.
- Start from
neorulset26/modules/README.md - Read
docs/guides/usage-and-safety.md - Treat modules as separate compatibility artifacts, not as the project's primary identity
- Start from
tools/README.md - Treat each tool as an independent reference subproject with its own deployment and compliance considerations
- Compatibility is not affiliation: compatibility with Surge is a technical property of some artifacts here, not a brand relationship.
- Documentation should define boundaries: project intent, legal limits, and maintenance scope should be explicit.
- Research before convenience: architecture, migration, and maintainability matter more than homepage-level consumption shortcuts.
- No service posture: the repository should not read like a hosted access product or managed network offering.
- Separation of concerns: configuration artifacts, modules, tools, and legal/development documentation should stay clearly separated.
- Published path stability: once public paths exist, migration needs to be managed deliberately rather than casually broken.
The active mainline under neorulset26/ contains text-based routing configuration artifacts and reference path documentation. Those materials are included as part of the repository's configuration research and maintenance work.
Representative maintained files include:
neorulset26/rules/common.listneorulset26/rules/paypal.listneorulset26/rules/socialsite.listneorulset26/rules/hulo.listneorulset26/rules/scholar.listneorulset26/rules/feishu.listneorulset26/rules/bytedance.listneorulset26/rules/ai.listneorulset26/rules/crypto.listneorulset26/rules/messenger.listneorulset26/modules/realip.sgmoduleneorulset26/modules/realip-ios.sgmoduleneorulset26/modules/realip.list
The v2.1.1 Real IP modules share 176 host tokens. Exact OpenClaw model and plugin catalog exceptions return real DNS answers while preserving the main profile's routing and application SSRF checks. The module README describes installation; the OpenClaw compatibility guide documents request-path differences and verification limits.
Additional structured materials live under:
neorulset26/ruleset/neorulset26/ruleset/Media/
These files are published as text artifacts for study, comparison, maintenance, and compatibility review. They should not be read as operational promises or endorsements regarding any third-party service, territory, platform policy, or enforcement posture.
tools/ holds operational reference utilities that support the broader configuration workspace without redefining the repository as a network service.
- Tools overview:
tools/README.md - DoH fallback reference:
tools/doh-fallback-worker/README.md - HTTP 204 probe reference:
tools/edge204/README.md - Real IP builder and opt-in OpenClaw compatibility probe:
tools/realip/README.md
The OpenClaw probe uses the locally installed SSRF runtime to check public DNS, two unauthenticated catalog requests, and offline special-address rejection controls. It is a manually invoked diagnostic, not a background service or security certification. It does not read user configuration or exchange tokens.
Each Cloudflare Worker under tools/ follows the same convention: a tracked wrangler.toml.example template, a real wrangler.toml that Git ignores, and a checked-in test suite runnable with node --test. Deployment examples use generic placeholders only. The public repository does not document maintainer-operated domains, account subdomains, routes, resource IDs, or tokens.
These components are provided as reference implementations. Anyone choosing to deploy or adapt them is solely responsible for platform compliance, lawful operation, security review, and production suitability.
This repository is maintained to reduce confusion about project scope, not to encourage aggressive use.
- No warranty is made that any artifact is accurate, complete, current, safe, or suitable for a particular environment.
- No promise is made that any configuration will reach, unlock, improve, or preserve access to any third-party service.
- No representation is made that repository contents satisfy the legal, regulatory, export-control, data-protection, security, procurement, or internal-policy requirements applicable to a given user.
- No operational security guarantee is made for self-deployment of reference tools or for downstream modifications made by users or redistributors.
If you are operating in a regulated environment, under enterprise security controls, or in a jurisdiction with sensitive network-tool restrictions, perform your own legal and security review before using any material here.
- Hardened the DoH Worker with private client-cache headers, separate public and authenticated cache namespaces, strict private DNS rule validation, fail-closed configuration handling, and streaming request/response limits.
- Added regression coverage and
python3 tools/check.pyfor rule/CIDR checks, informational cross-file overlap counts, local documentation links, Real IP synchronization, and offline tests. GitHub Actions runs the same checks; it does not deploy services or validate live device routing. - Released Real IP v2.1.1 for macOS and iOS/iPadOS with 176 shared host tokens.
Added exact
catalog.openclaw.aiandclawhub.aiexceptions after reproducing OpenClaw catalog failures caused by Surge Fake IP answers. - Preserved Enhanced Mode, existing outbound policies, and OpenClaw SSRF protection. No broad OpenClaw wildcard or DIRECT rule was introduced.
- Verified real system DNS, strict catalog GETs, unchanged routing, and actual model-catalog refresh on macOS. Both generated lists and native configuration syntax passed validation; on-device iOS testing remains separate.
- Added an opt-in diagnostic with nine offline SSRF rejection controls and documented why arbitrary URLs need a separately validated proxy boundary.
- Consolidated the public compatibility guide under
docs/guides/, updated module/tool references and usage notices, and retained private diagnostics outside the repository.
Previous repository milestones
- Released v2.1.0 of the macOS and iOS/iPadOS Real IP modules with a narrower 174-token catalog.
- Retained
captive.apple.comfor Apple connectivity detection and removedwww.apple.com,www.appleiphonecell.com, andgsp1.apple.comfrom forced Real IP handling. Apple websites, account pages, and store traffic now keep the consuming profile's normal Fake IP and outbound-policy behavior. - Extended the deterministic builder to synchronize module release metadata
and reject unexpected sections, non-
DIRECTmodule routing, platform marker drift, and macOS-only process rules in the iOS/iPadOS artifact. - Added unit coverage for catalog parsing and module safety boundaries. Existing Feishu/Lark/Doubao routing behavior and public module URLs are unchanged.
- Normalized eight IPv4/IPv6 CIDR entries to their equivalent network addresses without expanding or narrowing their effective match ranges, and removed five exact duplicate rules.
- Kept the published
.listfiles as the single directly referenced source for Surge, Mihomo/OpenClash, and Stash; no platform-specific mirror or compilation layer was introduced. - Moved international TikTok product coverage into
TikTok.listwhile keeping shared ByteDance infrastructure available to both policies. Consumer guidance now places TikTok before the broader ByteDance layer. - Removed forced-direct Apple Store and download overrides from
Special.list. Apple account, store, and download traffic now follows the user-selectable Apple policy, while service-specific Apple media rules retain higher priority. - Retained all existing absolute rule URLs while documenting FOX One under the
legacy
Fox Now.listpath, marking Fox+ as retired, and extending the legacyencoreTVB.listpath for TVBAnywhere North America.
- Introduced the v2.0.0 Real IP module architecture for macOS and iOS/iPadOS.
The modules centralize 177 verified
always-real-iphost tokens covering local networks, connectivity detection, captive portals, public Wi-Fi, real-time communication, authentication, established application compatibility, and Feishu/Lark/Doubao dependencies. - Added
neorulset26/modules/realip.listas the categorized canonical source andtools/realip/build.pyas the deterministic validator and renderer for both platform modules. - Added exact Real IP handling for
auth.openai.comso SSRF and anti-rebinding protection does not receive Surge's198.18.0.0/15Fake IP response. Its outbound policy remains controlled by the consuming profile. - Preserved the validated Feishu/Lark/Doubao direct-routing behavior and retired the superseded product-specific module files after successful live migration to the unified Real IP modules.
- Investigated recurring Feishu/Lark blank pages, slow external Wiki content,
and Chromium
ERR_TIMED_OUT (-7)failures under Surge Enhanced Mode. - Confirmed that the compatibility problem had two separate layers: several
product-qualified Feishu CNAME endpoints still received Fake IP responses,
while application-wide macOS
DIRECTrules also captured third-party web resources embedded inside Feishu/Lark and caused direct-connect timeouts. - Released v1.2.0 of the macOS module. It replaces blanket application routing
with
PROCESS-NAMEplus an inline shared-infrastructure ruleset, preserving direct routing for observed ByteDance dependencies without overriding the main profile's Google and external-site policies. - Released v1.2.0 of the iOS/iPadOS module with matching DNS/CNAME coverage and direct product routing, while retaining its platform-appropriate design with no macOS process rules.
- Added narrowly qualified Feishu and Feishu CDN CNAME patterns for
cdnbuild.net,bytedns1.com,cdngslb.com, andqueniusz.com, plus the observed Feishu creative CDN endpoint. Broad provider suffixes remain absent from global module rules. - Verified Mac/iOS parity across 71
always-real-iptokens, checked the macOS logical rules and six iOS CNAME routes, and validated temporary complete profiles with the nativesurge-cli --checkcommand. - Refreshed the legal boundary and added a repository-wide usage and safety notice covering review, backup, rollback, DNS/routing effects, diagnostic metadata, and the limits of remote publication.
- Removed the legacy root
modules/directory. ItsASN.China.sgmoduleandWeChat.sgmodulefiles were historical workarounds for WeChat in-app image sending failures under proxy/Fake-IP conditions, but their broad carrier and Tencent ASN-wideDIRECTrules were not product-specific and could not reliably address unresolved hostname traffic because they usedno-resolve. Maintained modules now live only underneorulset26/modules/.
- Expanded the platform-specific Feishu/Lark compatibility modules with the current product-domain set, scoped real-IP handling for observed CNAME targets, and direct routing for the Lark CDN.
- Added direct routing and Fake-IP compatibility for Doubao product domains.
- Replaced broad ByteDance infrastructure wildcards with product-qualified CNAME patterns. The modules add no shared DNS or domain-routing rules for general Douyin or Toutiao traffic and do not change the existing Bytedance or TikTok rule sets.
- Kept the macOS and iOS modules separate: only the macOS module contains
application process rules. Both modules remain free of
FINALrules and proxy policy groups. - Added installation and maintenance notes in
neorulset26/modules/README.md.
- Corrected the stated measurement boundary of the
tools/edge204/probe. The reading covers the whole chain from client through proxy node to the Cloudflare Anycast edge, not the node's egress alone. The client's own leg is inside every sample, so the same node measured from two different client ISPs will not produce the same number. - Documented a distinct failure mode found in the field: comparisons are only
valid between endpoints that cost the same number of round trips. A reading
is roughly
round trips × RTT of the weakest leg, so a TLS handshake, an uncached DNS lookup, or a redirect costs almost nothing on a good link and a great deal on a poor one, amplifying non-linearly under loss. A short-TTL self-hosted hostname measured against a universally cached endpoint can read 100 ms slower while both destinations are equally healthy. This looks exactly like node degradation and is not. - Added the diagnostic procedure for that case to the troubleshooting
section: confirm an
http://URL is not being upgraded, then compare both endpoints through the same node at the same protocol with the connect, handshake, and total times split out. - Changed the recommended global fallback from
cp.cloudflare.comtohttp://www.gstatic.com/generate_204. The former is operated separately from the Worker but shares AS13335, the same Anycast fabric, and the same edge infrastructure, which is not fault-domain isolation. Noted that the substitute must stay on plain HTTP to remain comparable, and that node pools with mainland-China egress should usehttp://captive.apple.cominstead, where the Google endpoint may be unreachable. - Corrected the
/traceexample output. It previously showedasn=13335, which is Cloudflare's own ASN and the single most misleading value the field can take. The example now shows a proxy egress ASN, and the text states thatasnis the network Cloudflare sees the request arriving from — seeing13335there means the measured path was not the intended one. - Worker source and test suite are unchanged. This revision is limited to
measurement semantics and documentation, applied to both
README.mdandREADME.ja.md.
- Revised the
tools/edge204/HTTP 204 probe after an audit. Response headers were reduced to a singleCache-Control: no-store, trailing slashes are now normalized,/pingreports the deployed version, and the client IP on/traceis gated behind an optionalTRACE_KEYthat degrades silently rather than signalling that a key exists. - Documented the limits of the measurement method itself: Anycast bias toward Cloudflare-adjacent egress, plaintext port 80 as an unreliable channel, and the single point of failure created by pointing every health check at one hostname. The prior TLS-overhead rationale was corrected — an extra handshake scales readings proportionally and does not by itself reorder nodes.
- Added Clash / mihomo health-check configuration alongside the existing Surge examples, covering group-level and provider-level checks.
- Aligned
tools/edge204/with the deployment convention already established bytools/doh-fallback-worker/: a trackedwrangler.toml.example, a gitignored real config, and a checked-in test suite. - Replaced an unsound cache verification step. Comparing
/pingtimestamps proves nothing, because the Workers clock does not advance without I/O;cf-rayand the absence ofAgeare used instead. - Broadened the
.wrangler/ignore rule to match at any depth, since Wrangler writes its cache into whichever directory it is invoked from.
- Hardened the
tools/doh-fallback-worker/reference implementation with validated hedged upstream requests, transaction-ID and DNS TTL correction on cache hits, RFC 2308 negative caching, semantic cache isolation, isolate-local singleflight, bounded requests, and hot-only prefetch. - Consolidated maintained behavior, operational boundaries, verification steps, and development history into the component README files.
- Removed the temporary audit handoff document after accepted findings were incorporated into source and tests.
- Standardized all DoH deployment examples on generic placeholders. The public repository does not document maintainer-operated resolver domains, account subdomains, routes, resource IDs, tokens, or other private deployment data.
- Fully retired and removed the
archive/legacy/directory, including all historical root rules, the oldruleset/tree, and the legacyMIGRATION_RULE_URLS.mdmirror. - Reason: the migration window that justified keeping a legacy mirror has closed.
neorulset26/is the only maintained mainline; preserving a parallel legacy surface caused path ambiguity, duplicated maintenance, and gave new users the false impression that retired publication paths were still supported. - Reality: any downstream still pointing at
archive/legacy/...URLs will now receive 404 responses and must switch to the equivalents listed inneorulset26/RULESET_URLS.md, usingneorulset26/MIGRATION_RULE_URLS.mdfor path mapping. Legacy path compatibility is no longer provided and will not be restored. - Updated
README.md,docs/development/repository-layout.md,docs/development/collaboration-guide.md, anddocs/reference/rules.mdto remove all references to the retired archive surface.
- Established
docs/legal/LEGAL.mdwith full jurisdictional compliance notice, trademark acknowledgment, and liability disclaimer. - Restructured project documentation to reflect research and configuration architecture scope.
- Revised
ENGINEERING_GUIDE.mdandRULESET_URLS.mdto align with project positioning.
- Updated
tools/doh-fallback-worker/toward a token-aware private DoH gateway design. - Expanded Worker-side DNS response synthesis, cache normalization, and stale-if-error behavior.
- Added deployment-oriented documentation for the Worker reference implementation.
- Preserved
neorulset26/as the active configuration mainline. - Moved shared modules into
modules/. - Moved repository and collaboration notes into
docs/. - Archived historical root-level materials into
archive/legacy/.
- Formalized
tools/as a support layer for operational helpers. - Added repository-level tool documentation.
- Added migration-oriented URL references for the active configuration line.
- Continued maintenance and categorization work across the configuration tree.
- Reduced external dependency exposure in the maintained configuration materials.
- License: MIT License
- Legal boundary:
docs/legal/LEGAL.md - Usage and safety:
docs/guides/usage-and-safety.md - Contribution standard: prefer accuracy, maintainability, traceable changes, and risk-aware documentation
There is something quietly humbling about watching an AI system, capable of working through pages of code, come to a halt before a single address. A name is resolved, a boundary is checked, and the conversation with the outside world stops. So much of what we call intelligence still depends on these small permissions to proceed.
A proxy gives the network another vocabulary. Names become temporary addresses; a request takes a different road. Such translations can make distant things reachable, yet something understood by one layer may look like a warning to the next. Working where AI meets this machinery has made me wary of effortless promises. I want tools whose decisions I can trace, whose boundaries I can understand, and whose mistakes leave enough evidence for someone to put things right.
For me, progress often lives in an unremarkable moment: a request finally arrives without a safeguard being dismantled to let it through. The page opens. Work resumes. The repair disappears into the ordinary day it has made possible. I find more hope in that quiet usefulness than in another promise that everything will soon run itself.
To my friends at Kyoto University, thank you for the kindness, encouragement, and strength you have given me. Your support reaches into work you may never see, including these small acts of patience with an imperfect network. I hope some of that care travels onward with what I build.
Third-party routing configuration research repository
Surge-compatible artifacts are provided only as compatibility materials, not as product affiliation
Copyright © 2023-2026 YAGAMI
Last updated: September 4, 2026 7:43:49 PM PDT (America/Los_Angeles)