From Exposed to Invisible: Evolution of My Cross-Border Home Network Architecture (Phase B)

Posted on Views:

Abstract: In the previous post, I used FRP + VPS to bridge my home networks in China and the US, creating a private “Residential IP Proxy Pool.” However, in the Phase A architecture, the system exposed multiple ports (7000, 8900, 10087), which was not elegant and posed a risk of active probing by the GFW.

Today, I completed the Phase B Architecture Upgrade: using WebSocket + Nginx Reverse Proxy to funnel all management traffic, tunnel traffic, and proxy traffic into a single port: 443. To the outside world, this is just a static tech blog with SSL deployment.

1. The Pain Point: Port Anxiety

In the Phase A architecture, my VPS firewall was like a sieve:

  • :7000: FRP Server Communication Port (Exposed)
  • :7500: FRP Dashboard (Exposed)
  • :10087: Mac Node Proxy Entry (Exposed)
  • :8900: Traffic Monitoring API (Exposed)

This configuration had two fatal flaws:

  1. Obvious Fingerprint: The TCP protocol characteristics of FRP are easily identifiable, making it fragile during high-sensitivity periods.
  2. Security Risks: Any port scanning script could discover non-HTTP services running here, increasing the risk of brute-force attacks.

Goal: Expose only :443 (HTTPS) and :80 (Redirect), binding all other ports to 127.0.0.1 so they are inaccessible from the outside.

2. Core Solution: Protocol Camouflage and Routing

To achieve “All-Site 443,” I adopted Nginx as a Unified Gateway, combined with the WebSocket (WSS) protocol for traffic routing.

Architecture Diagram



graph TD
    User["External Visitor / Client"] -->|"HTTPS (443)"| Nginx["Nginx Gateway (VPS)"]
    
    subgraph VPS ["VPS Server"]
        direction TB
        Nginx
        Blog["Static Blog (/www/wwwroot)"]
        FRPS["FRP Server (:7000)"]
        Proxy["Mac Node Reverse Proxy (:10087)"]
    end
    
    Nginx -->|"Default Access"| Blog
    Nginx -->|"Header: Upgrade=websocket"| FRPS
    Nginx -->|"Path: /vmess-mac"| Proxy
    
    FRPS <==>|"FRP Tunnel"| MacNode["Mac Home Node"]

2.1 First Layer of Camouflage: FRP “Parasitism”

Although FRP officially supports WebSocket mode, newer versions (v0.67.0+) have compatibility issues with custom paths. For maximum stealth, I used a lower-level Header Hijacking scheme.

In the Nginx root / configuration:

  1. Default: Returns the static blog under /www/wwwroot (the “camouflage” site you are seeing now).
  2. Special Case: If the request header contains Upgrade: websocket and does not match other specific paths, it is judged as an FRP client, and traffic is forwarded directly to the local listener at :7000.
1
2
3
4
5
6
7
8
9
10
11
location / {
    # Core Logic: Detect WebSocket Header
    # If it's a WebSocket connection, treat as FRP traffic
    if ($http_upgrade = "websocket") {
        proxy_pass http://127.0.0.1:7000;
    }
    
    # Normal visitors (browsers) see the blog
    root /www/wwwroot/blog.example.com;
    index index.html;
}

This means when the FRP client connects to wss://blog.example.com:443, Nginx automatically performs a “bait and switch.” From outside the firewall, this looks exactly like a persistent HTTPS request.

2.2 Second Layer of Camouflage: Proxy Data Stream “Invisibility”

In the previous architecture, clients like Shadowrocket connected directly to the VPS at port :10087, sending raw TCP traffic.
Now, I require the Mac X-UI node to change its inbound protocol to WebSocket and specify a hidden path (e.g., /vmess-mac).

Nginx Routing Rules:

1
2
3
4
5
6
7
8
9
10
# Identify specific path, forward to Mac Node's reverse proxy port
location ^~ /vmess-mac {
    proxy_pass http://127.0.0.1:10087; # This is the port mapped by FRP on the VPS
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    
    # Pass real IP, though strictly maybe not effective behind FRP, it's good practice
    proxy_set_header X-Real-IP $remote_addr;
}

Thus, all proxy traffic becomes standard HTTPS requests. The path https://blog.example.com/vmess-mac looks just like a blog API endpoint or a static resource, blending perfectly into normal web traffic.

3. Automated Ops: Refusing Manual Configuration

To support this upgrade, all client configurations must be updated synchronously. Manually changing dozens of configs (Android, iOS, Mac, Windows) is tedious and error-prone. I refactored the Python sidecar script (sync_mac.py).

The current logic is:

  1. Mac Boot
  2. Pull VPS Config (Get latest UUID and Port Mapping)
  3. Force Database Update (Ensure local X-UI settings comply with stealth protocol)

The script automatically connects to the local SQLite database, forces the Inbound protocol to WebSocket, and locks the Path:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# Automation Snippet: Force Protocol Correction
new_stream_settings = {
    "network": "ws",
    "security": "none",
    "wsSettings": {
        "path": "/vmess-mac", # Path must match Nginx
        "headers": {}
    }
}

# Operate directly on DB, bypassing potential UI mistakes
cursor.execute(
    "UPDATE inbounds SET stream_settings = ? WHERE port = ?", 
    (json.dumps(new_stream_settings), local_port)
)

This ensures that no matter how the panel settings are messed with, a container restart will automatically revert traffic to the correct “Phase B Stealth Mode.” This guarantees my system only permits traffic that complies with the new architecture.

4. Final Form and Reflections

After this overhaul, my VPS state is now:

  • Open Ports: Only 80 (HTTP Redirect), 443 (HTTPS), 22 (SSH).
  • Web: A beautiful, legitimate static personal homepage.
  • Hidden Services:
    • Traffic Monitoring API (/report)
    • Mac Residential Proxy (/vmess-mac)
    • Android Residential Proxy (/vmess-android)
    • FRP Control Plane (Routed by Nginx)

This is essentially a prototype of a DePIN (Decentralized Physical Infrastructure Network). Unlike Honeygain or Grass, this system is entirely under my control—data sovereignty is mine, network quality is mine, and there are no middlemen taking a cut or monitoring traffic.

In an era where data is monopolized by tech giants, owning a set of completely independent, indestructible physical network infrastructure is perhaps the ultimate romance for a geek.

Next Step: I plan to research optimizing connection stability on mobile devices or introducing UDP over WSS technology to improve throughput for video streaming.