Proposal: MASQUE CONNECT-IP across Outline Client, Server, and Manager — implementation experience and field observations

[JieMeiDev]

Hi Outline team,

I would like to share a downstream project spanning Outline Client, Server, and Manager, explain the practical benefits that motivated it, and ask whether this direction would interest the maintainers before preparing contributions for upstream review.

The project explores replacing the Shadowsocks data plane with MASQUE CONNECT-IP over HTTP/3 while retaining as much of Outline's administration workflow and user experience as possible. This is a self-maintained experimental branch, not an official Outline release.

Motivation and field observations

The initial use case was an OpenWrt gateway serving devices on a local network in Shanghai, with an international egress path through AS9929.

In everyday use over a cross-border network path, I have observed better performance and greater resilience with the MASQUE implementation than with my previous proxy setup. Slowdowns and disruptions that appeared consistent with interference or QoS were less frequent or less severe. These practical improvements motivated work beyond the gateway into Client, Server, and Manager integration.

These are deployment-specific observations, not a controlled demonstration of their cause or a claim that HTTP/3 universally avoids blocking or throttling. I do not yet have a sufficiently controlled comparative dataset to give a reliable percentage improvement.

Existing records cover approximately two weeks of production use, including development, upgrades, and troubleshooting. This is not uninterrupted uptime on one release. Transient H3 timeouts and automatic recovery have been observed, and the latest gateway revision has a shorter observation window. Longer-term availability measurements remain to be collected.

Scope and implementation status

A usable deployment needs more than a tunnel. The work follows the familiar Outline workflow:

Install a server → add it to Manager → create and share an access key → import it into a client → connect.

I am presenting the overall design together because protocol, credential management, and client integration depend on one another. Contributions could subsequently be split into smaller reviewable stages.

Server

The MASQUE-only prototype implements CONNECT-IP forwarding, authentication, per-key address leases, session isolation, and credential revocation. Isolated integration tests have exercised traffic for multiple credentials and selective revocation without interrupting another user's connection.

The management backend is not yet a complete reuse of upstream. Runtime integration with the existing management model, persistent metrics, quotas, installation, upgrades, and rollback still require work.

Manager

The adaptation reuses the upstream Manager application, server list, access-key table, sharing dialog, and settings UI through a MASQUE-specific adapter.

Local Electron/container integration has exercised server import, key creation, renaming, credential sharing, persistence across application restarts, and selective revocation.

Complete metrics, quota enforcement, configuration-link distribution, installation, and release workflows are unfinished. Credential-sharing tests do not imply a complete hosted configuration-sharing service.

Client

Work includes a proposed CONNECT-IP configuration type, parsing and import, an HTTP/3 connector, packet-device integration, and experimental Go/Apple platform adapters.

Tests cover packet forwarding, cancellation, reconnection, authentication and certificate failures, and resource cleanup. Apple work includes compilation and selected Go/Swift integration checks.

A complete native Outline Client VPN connection has not yet been validated on a physical device. The working OpenWrt gateway should be distinguished from unfinished desktop/mobile app integration.

OpenWrt

The gateway integrates the shared CONNECT-IP implementation with service management, routing, firewall rules, DNS forwarding, and operational statistics. It also retains an SDK-based Shadowsocks option.

Existing validation covers dual-stack TCP/UDP forwarding, service lifecycle behavior, firewall reloads, and deployment checks on x86-64 routers. Long-duration load testing, physical reboot acceptance for the latest candidate, and ARM64 device validation remain outstanding.

Architecture and compatibility

The broader Client/Server/Manager experiment targets a MASQUE-only branch. That is a downstream scope choice, not a proposal to remove Shadowsocks from upstream Outline.

The proposed access configuration is distinct from ss:// credentials. Existing Outline clients do not automatically understand it; reuse of configuration fetching does not imply protocol compatibility.

CONNECT-IP wire behavior, authentication, address allocation, and configuration distribution are separate design concerns. Current authentication and configuration choices are prototype conventions; general interoperability with other MASQUE clients has not been established.

For SDK integration, I would like to explore reusing network.IPDevice, with an initial implementation kept experimental in the x module. OpenWrt-specific routing, firewall policy, and UI would remain outside the SDK.

Dependency-version differences and local QUIC-related patches would need documentation and review before extraction into an upstream contribution.

Feedback requested

1. Is MASQUE CONNECT-IP a direction Outline would consider exploring?
2. What architectural, operational, or censorship-resistance concerns should be addressed first?
3. What comparative measurements would make these field observations useful to the project?
4. What boundaries would you prefer between the SDK, Server, Client, and Manager?
5. Would a focused design document and minimal client/server interoperability example be a useful first contribution?
6. Where should this cross-repository discussion be coordinated?

I recognize the substantial implementation and maintenance responsibilities. I am not asking for the entire downstream branch to be accepted together or for an immediate support commitment.

My aim is to explain the complete use case, share observed benefits and limitations, and learn whether there is a path toward smaller upstream contributions. I can prepare sanitized architecture notes, reproducible examples, and selected test evidence.

@fortuna, I would particularly appreciate your perspective given your work on Outline transports and MASQUE integration.

Thank you for your time and for building Outline.