feat: add tcp relay using websocket

[jj28-arch]

Add WebSocket TCP Relay Support

Summary

This PR adds full TCP tunneling support over WebSocket relays.

Previously, the project only supported HTTP-based relay traffic through Google Apps Script and optional exit nodes. With this change, SOCKS5 TCP traffic can now be forwarded through WebSocket-based TCP relays deployed on Cloudflare Workers or Deno Deploy.

Features

• WebSocket TCP tunneling
• SOCKS5 TCP CONNECT support
• Cloudflare Workers TCP relay support
• Deno Deploy TCP relay support
• Optional domain fronting support
• Bidirectional raw TCP proxying
• Keepalive ping/pong
• SSH-friendly low latency (TCP_NODELAY)

Added

Client

• New tcp_ws_relay configuration block
• Async WebSocket TCP tunnel implementation
• RFC6455 frame encoder/decoder
• TLS + optional domain fronting support

Relays

• Added TCP relay support to:

  • apps_script/cloudflare_worker.js
  • apps_script/deno_deploy.ts

Example Config

"tcp_ws_relay": {
  "enabled": true,
  "ws_url": "wss://your-relay/tcp",
  "auth_key": "CHANGE_ME",
  "front_domain": null,
  "front_ip": null,
  "connect_timeout": 15,
  "ping_interval": 20
}

Notes

• Existing HTTP relay functionality remains unchanged
• TCP relay is optional and disabled by default
• No external Python dependencies added

[ZoodSood]

Appreciate the effort!

That said, I think this is a bit outside the scope of what this project is trying to do.

To give some background: the main folks who'd benefit from a tool like this are users in places like Iran, where access to Western services is super limited — basically just Google and GitHub (yep, not even Cloudflare!). So an HTTP relay that hides traffic inside Google searches actually makes a lot of sense for them.

A TCP/WebSocket relay with “optional domain fronting,” on the other hand, is effectively another general‑purpose proxy solution. While there’s nothing wrong with that, I think such a feature would be better maintained in its own dedicated repository.

I'd rather keep MasterHTTP focused on doing one thing really well and keeping deployment as dead-simple as possible. Let's keep it lean and on track.

[jj28-arch]

Appreciate the effort!

That said, I think this is a bit outside the scope of what this project is trying to do.

To give some background: the main folks who'd benefit from a tool like this are users in places like Iran, where access to Western services is super limited — basically just Google and GitHub (yep, not even Cloudflare!). So an HTTP relay that hides traffic inside Google searches actually makes a lot of sense for them.

A TCP/WebSocket relay with “optional domain fronting,” on the other hand, is effectively another general‑purpose proxy solution. While there’s nothing wrong with that, I think such a feature would be better maintained in its own dedicated repository.

I'd rather keep MasterHTTP focused on doing one thing really well and keeping deployment as dead-simple as possible. Let's keep it lean and on track.

Thanks for your attention. I know about the level of censorship in Iran. I live in Iran too. The thing is censorship is leveled. Currently only google is accessible, but if the level decrease only a bit, cloudflare would be accessible and this method could be easily used. Protocols like ssh which are almost mandatory in the jobs of many people including myself, could be accessible using this method. Also the config is as simple as it gets. The only difference is you should deploy a different script. That said, since the name of the project is masterhttprelay, the functionality of my changes might not totally match the name of the repository.

[ZoodSood]

Thanks for your attention. I know about the level of censorship in Iran. I live in Iran too. The thing is censorship is leveled. Currently only google is accessible, but if the level decrease only a bit, cloudflare would be accessible and this method could be easily used. Protocols like ssh which are almost mandatory in the jobs of many people including myself, could be accessible using this method. Also the config is as simple as it gets. The only difference is you should deploy a different script.

You are right about the levels of censorship. Guess we'll have to see how things develop. But then, if Cloudflare becomes accessible, the good-old name server records proxy also becomes accessible which already powers millions of V2Ray and MTProto tunnels.

That said, since the name of the project is masterhttprelay, the functionality of my changes might not totally match the name of the repository.

The README also mentions: "This project is centered on the Apps Script relay."

[DarkestViolet]

Hi, thank you for your effort in advance. I need to use this but I'm not an expert. Can you explain how exactly to deploy deno.tcp.relay.ts on Deno? I only get URLs that end with deno.net.

[jj28-arch]

Hi, thank you for your effort in advance. I need to use this but I'm not an expert. Can you explain how exactly to deploy deno.tcp.relay.ts on Deno? I only get URLs that end with deno.net.

Hi.
The url is ok, you just need to change the http:// stuff to wss:// and also add a /ws to the end. Just like how it looks in the example.json but with your own domain name