AIO Ep10. Access Any Internal/Third-party TCP Service via Synology QuickConnect

Synology QuickConnect is a built-in NAT traversal feature that allows DSM to access your NAS from the internet. With the help of third-party “whitening” services available on Taobao, even self-built “Hackintosh-style” Synology (non-official) systems can use QuickConnect for NAT traversal.

QuickConnect works seamlessly with official Synology apps — just enter your QuickConnect ID, and it automatically switches between internal and external networks.

However, the downside is that QuickConnect only works within official Synology apps, many of which have poor user experiences and lack basic features.

In AIO Ep.9, I discussed using IPv6 with DDNS. And in this article about the Phicomm N1 box, I demonstrated transparent proxying to access any internal service. However, given that IPv6 is still not universally adopted, this method remains inconvenient (e.g., many Wi-Fi networks don’t support or enable IPv6 by default, requiring mobile hotspot tethering).

After some research and experimentation, I finally found a way to route all application traffic through QuickConnect — effectively bypassing the need to set up or pay for a reverse proxy. Squeezing every last drop from the free tier. I’ve documented the process below.

Basic Version (HTTP) and Inspiration

Searching Google with keywords like QuickConnect third-party, I found two helpful articles:
Synology Tinkering Part 1: QuickConnect Reverse Proxy + IPv4 + Transmission and
Access Third-party Web Apps via Synology QuickConnect.
The core idea is explained as follows:

QuickConnect is essentially Synology’s built-in NAT traversal service (similar to花生壳/Oray). The DSM connects to Synology’s servers, registers itself, and establishes a TCP tunnel. When external users access the QuickConnect domain, their traffic is routed back through this tunnel — which ultimately lands on DSM’s Nginx server. Since it’s routed through Nginx, we can modify its reverse proxy configuration to access other third-party services.

Using this method, you can access any internal HTTP service via Nginx’s proxy_pass directive.

Advanced (All TCP/UDP Services, Even Other Internal Hosts)

If you only need to expose a few HTTP services (e.g., Emby, Transmission), the above method is sufficient.

But when dealing with many HTTP services, manually configuring each one becomes tedious. And for non-HTTP services like SSH or RDP, this method simply doesn’t work.

So naturally, the next step is to encapsulate other types of traffic into HTTP-compatible formats — enter V2Ray’s WebSocket (ws) mode.

1

Principle: Client TCP traffic <=> Encapsulated WebSocket <=> QuickConnect Server <=> NAS Nginx <=> V2Ray Server decapsulates and forwards

The main role of V2Ray here is to trick Nginx and the QuickConnect server into treating the traffic as legitimate HTTP/WebSocket data, rather than dropping it as unrecognized.

One important caveat: QuickConnect has built-in logic to switch between internal and external access. If a client directly sends an HTTP request to name.cnx.quickconnect.cn, it gets redirected to name.quickconnect.to, which then performs additional checks and issues an HTTP 307 redirect based on network context. However, V2Ray clients can’t handle such redirects and will fail immediately.

After packet capturing and testing with Fiddler, I discovered that the key to bypassing this redirect lies in the Cookie header. Adding Cookie: type=tunnel forces QuickConnect to use the reverse proxy path directly, skipping the redirect. Conveniently, most proxy tools allow custom headers in WebSocket connections — so this requirement is easy to meet.

Below are the detailed setup instructions >>>

• Server Side (NAS)

1. Configure Nginx

Create a file named dsm.proxy.conf in /usr/syno/share/nginx/conf.d.

Add the following content and save. (You can reload the config with nginx -s reload if needed.)

1
2
3
4
5
6
7
8
9
10
11
12
13
14

location /reverse_proxy {
    proxy_redirect off;
    proxy_pass http://127.0.0.1:10000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    # Default timeout is 60s, which may cause disconnections
    proxy_read_timeout 3000;
    proxy_connect_timeout 3000;
    proxy_send_timeout 3000;
}

2. Set up the server (Docker recommended). Example config:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

{
	"inbounds": [{
		"port": 10000,
		"listen": "[::]",
		"protocol": "vmess",
		"settings": {
			"clients": [{
				"id": "your-own-UUID-here",
				"level": 1,
				"alterId": 0
			}]
		},
		"streamSettings": {
			"network": "ws",
			"security": "none",
			"wsSettings": {
				"path": "/reverse_proxy",
				"headers": {
					"Cookie": "type=tunnel"
				}
			}
		}
	}],
	"outbounds": [{
		"protocol": "freedom",
		"settings": {}
	}]
}

Make sure network is set to ws, and include "headers": {"Cookie": "type=tunnel"}.

At this point, if you access your-QC-ID.quickconnect.to/reverse_proxy from an external network (e.g., mobile data) using a browser and see Bad Request, your server setup is correct.

• Client Side

Example configuration:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

{
	"inbounds": [{
		"tag": "socks",
		"port": 10808,
		"listen": "127.0.0.1",
		"protocol": "socks",
		"sniffing": {
			"enabled": true,
			"destOverride": [
				"http",
				"tls"
			]
		},
		"settings": {
			"auth": "noauth",
			"udp": true,
			"allowTransparent": false
		}
	}],
	"outbounds": [{
		"tag": "proxy",
		"protocol": "vmess",
		"settings": {
			"vnext": [{
				"address": "replace-with-your-own-QuickConnect-ID.cnx.quickconnect.cn",
				"port": 443,
				"users": [{
					"id": "your-own-UUID-here",
					"alterId": 0,
					"email": "t@t.tt",
					"security": "auto"
				}]
			}]
		},
		"streamSettings": {
			"network": "ws",
			"security": "tls",
			"tlsSettings": {
				"allowInsecure": false
			},
			"wsSettings": {
				"path": "/reverse_proxy",
				"headers": {
					"Cookie": "type=tunnel"
				}
			}
		}
	}]
}

Note: Since QuickConnect provides its own HTTPS certificate, WebSocket must be configured with "security": "tls". Also ensure "headers": {"Cookie": "type=tunnel"} is correctly set.

p.s. If you’re using ShadowsocksR/Clash (aka “Little Kitty”), be aware: QuickConnect identifies the target via the Host header. However, some clients automatically append :443 to the Host (e.g., xxx.cn2.quickconnect.cn:443), which causes recognition failure. To fix this, manually override the Host header: add Host: xxx.cn2.quickconnect.cn in your headers.

<<< End of configuration

After completing the setup, you should now be able to access any TCP service on your server via a SOCKS5 proxy. For applications that don’t support SOCKS5 (e.g., RDP), you may need to use TUN mode or gateway proxy techniques. For gateway proxy setup, refer to this article about the N1 box. For TUN mode, just Google it.

I’ve tested the speed a few times — download and upload speeds consistently reach 10–20 Mbps, surpassing most common NAT traversal services and low-end VPS options. Ping is around 400 ms, making SSH and RDP usable and generally smooth.