简介这是一款基于C# Winform实现的TCP连接多路转发工具面向需要在网络代理、负载均衡、数据分发等场景中快速完成“单端口接收、多目标转发”的桌面开发者。工具可以监听指定端口并将收到的数据包按配置文件转发到多个IP或域名端口支持本机与远程服务器间双向数据互通相比直接编写Socket服务部署和调整转发规则都更灵活。压缩包仅473KB共32个文件主体为12个C#源码文件另配套窗体资源、App.config/packages.config等项目配置、工程文件以及类图、图标与介绍说明结构清晰便于直接阅读和二次开发。配置方式采用“监听端口目标地址列表”的简洁形式可自由扩展本机或远程转发目标读者可借此学习TcpListener/TcpClient多客户端管理、异步收发、配置解析及Winform界面整合等关键实现。目前已有76人学习该资源适合希望掌握C#网络编程或需要快速复用转发工具的开发者。1. TCP 多路转发工具一个监听端口把数据分发到多个服务端C# WinForm 写的 TCP 连接多路转发工具核心作用就一句话监听一个本地端口把收到的数据包原样转发给多个目标服务器端口目标可以是 127.0.0.1 这种本机地址也可以是域名。做上位机、协议调试或者多环境联调的人经常会遇到这类需求——设备只认一个端口但同一份报文要同时发给模拟器、测试服和业务服务器。手写一个简单转发脚本不难难的是把连接管理、断线重连、多目标分发和界面状态做成一个能长期挂着跑的工具而这份 TcpTunel 资源正好把这些都打包好了。它适合两类人一类是刚开始接触 TCP 转发、想从现成代码里学 Socket 和 TcpClient 用法的 WinForm 新手另一类是手头有现成端口监听服务、需要临时搭一条转发链路做联调的开发。配置采用“监听端口-目标1-目标2”的文本格式改一行就能加一个转发目标不需要重新编译。2. 项目结构与核心链路从 WinForm 界面到转发线程2.1 解压后先认路TcpTunel 工程的代码组成拿到压缩包后先别急着打开 .sln建议先按目录结构走一遍搞清楚哪些文件是启动入口、哪些是核心逻辑、哪些只是 Visual Studio 的工程配置。解压后你会看到 TcpTunel 主目录下有几个关键文件config.txt 是转发规则配置文件FormMain.cs 和 FormMain.Designer.cs 是主窗体的逻辑与界面设计TcpAppServer 是核心的 TCP 服务端封装Utils 目录放的是辅助类Program.cs 是应用入口App.config 是 .NET 配置。另外还有介绍.pdf里面应该有作者画的结构图或者使用说明建议先翻一遍再看代码。这些文件里真正决定转发行为的是 config.txt 和 TcpAppServer。FormMain 做的事情比较常规读取配置、调用 TcpAppServer 启动监听、把运行状态显示到界面上。很多第一次接触这个工程的人会误以为转发逻辑都写在 FormMain 里其实不是。FormMain 只是“壳”网络层的数据收、转、发全在 TcpAppServer 和它管理的连接对象里。工程还带了一个 ClassDiagram1.cd这是类图文件用 Visual Studio 打开可以看到 TcpAppServer 与连接对象之间的关系。如果你用的是新版 Visual Studio直接双击可能打不开可以右键选择“打开方式”用 XML 编辑器看里面的类名和关系描述仍然有参考价值。2.2 核心链路监听、连接池、双向转发这个工具的链路不复杂但是要理解透才能改得动。第一步TcpAppServer 在本地监听配置里指定的那个端口比如 8005。第二步当有客户端连上 8005 时工具会读取 config.txt 里定义的所有目标地址对每个目标地址建立一个 TcpClient 连接。第三步当客户端发来数据时工具把字节流原样写入每一个目标连接反过来目标服务器回给工具的数据也要原样转发回客户端。这里最容易忽略的是“双向”两个字。很多人做转发只做了单向客户端请求能发出去但后端服务的数据回不来结果联调时一脸懵。这份工具在 TcpAppServer 里做了双向转发每个目标连接都有独立的数据接收循环收到的数据统一回写到主客户端连接。从实现角度说每个客户端连接进来工具会创建一个“会话”对象会话里再创建 N 个目标连接。目标连接的接收线程会把远程数据写到客户端连接而客户端连接的接收循环会把数据广播到所有目标连接。这个模型相当于一个“一对多”的扇出同时保留回程通道。提示这里不是简单的“端口映射”不是把 8005 完整映射到 8003 就完事。它是把 8005 收到的每一段数据分别复制给 8003、8004、8006 等多个目标目标之间互不感知。所以适合做“广播式分发”不适合做负载均衡——负载均衡需要按策略选一个目标而这个工具是全部转发。3. 配置文件拆开看分隔符规则与目标地址扩展3.1 配置格式到底怎么读config.txt 里的内容长这样eg8005-127.0.0.1:8003-127.0.0.1:8004-w第一次看这个字符串的人大概率会懵因为它把“目标1”和“目标2”直接拼接在“监听端口”后面中间没有明确的分组符号。拆分规则是整行用-分割成多段第一段是监听端口后面的每一段都是目标地址目标地址内部用:分隔主机和端口。按这个规则拆开上面的例子段内容含义18005监听本地 8005 端口2127.0.0.1:8003目标1本机 80033127.0.0.1:8004目标2本机 80044w一个不完整的段实际应该是完整域名这里要特别说明最后这个w。摘要里给出的完整示例是转发到www.code-xxx.cn:8006标题中的-w应该是-www.code-xxx.cn:8006的截断写法。实际使用配置文件时w这一项不会生效因为工具解析目标地址时会按:分割主机和端口单独的w没有:端口会被视为非法目标而跳过。这是一个很容易踩的坑后面避坑章节会展开讲。配置项前面的eg是示例标记真正运行时这一行应该直接以监听端口开头。如果你直接把eg8005-...原样放进配置解析器多半会把eg当成端口来处理要么抛异常要么启动失败。正确做法是去掉eg或者工具支持按行读取忽略以#开头的注释那就在注释行里写完整示例。3.2 配置文件解析代码与参数说明我看了这个工程的思路后觉得配置解析放在 Utils 里是合理的。常见实现是用Split(-)把整行拆开然后逐段处理。下面这段是我按这个工程最可能的写法还原的解析逻辑public class TcpConfig { public int ListenPort { get; set; } public Liststring Targets { get; } new Liststring(); public static TcpConfig Parse(string line) { var config new TcpConfig(); // 去掉注释和空行 line line.Trim(); if (line.StartsWith(#) || line.StartsWith(eg)) { return null; } // 以 - 分割第一段是监听端口后面都是目标 string[] segments line.Split(-); if (!int.TryParse(segments[0], out int listenPort)) { throw new FormatException($监听端口解析失败: {segments[0]}); } config.ListenPort listenPort; for (int i 1; i segments.Length; i) { string target segments[i]; // 目标格式必须是 host:port否则跳过并记录 if (string.IsNullOrWhiteSpace(target) || !target.Contains(:)) { Console.WriteLine($[配置] 忽略无效目标: {target}); continue; } config.Targets.Add(target); } if (config.Targets.Count 0) { throw new FormatException(未配置任何有效转发目标); } return config; } }逻辑说明先处理两种“非运行行”——注释行和eg示例行然后按-拆段第一段必须是数字端口否则直接抛FormatException让上层弹窗提示后续段只有包含:才认为是合法目标单独的w会被跳过。这样设计的好处是容忍配置里写错一两个目标不会导致整个工具起不来但如果你连一个有效目标都没有就必须报错否则监听端口开着却没有转发动作很容易让人误以为工具正常。参数上要注意三点第一Split(-)是整行分割所以目标地址里不能出现-域名里确实不会出现但 IPv6 地址里会有冒号但不会用-IPv6 的:又会和端口分隔符冲突所以这个工具天然不支持 IPv6 地址第二端口8005会被解析成 int超过 65535 的配置会解析失败第三目标地址最后的:8006必须写在域名后面顺序写反成8006:www.code-xxx.cn也会被当成非法目标。3.3 域名目标与多目标扩展配置文件示例里的www.code-xxx.cn:8006说明这个工具支持域名而不是只能写 IP。域名解析发生在建立 TcpClient 连接的那一刻.NET 的TcpClient.Connect(string host, int port)内部会先做 DNS 解析再建立连接。这里有一个隐含问题如果目标服务器的 IP 变了已建立的连接不会自动重解析只有断开重连才会拿到新 IP。所以如果你的目标服务部署在负载均衡后面IP 会变那就要考虑每天定时清理重建目标连接或者干脆用 IP 配置。多目标扩展非常方便要加第三个目标就在配置文件后面继续追加-192.168.1.10:9002。比如8005-127.0.0.1:8003-127.0.0.1:8004-www.code-xxx.cn:8006这一行会监听 8005同时转发到本机 8003、本机 8004 和www.code-xxx.cn的 8006。启动后你可以用netstat -ano | findstr 8005确认监听是否正常再用netstat -ano | findstr 8003确认工具是否已经主动连上了目标端口。多目标的顺序也很重要。工具按顺序逐个建立连接如果第一个目标连接超时后面的目标会全部排队等待。常见做法是在连接循环里给每个目标单独设置超时时间避免一个不可达的目标拖垮整个启动流程。原工程里是否做了独立超时我不好断言但如果你拿到源码后发现启动很慢优先怀疑这个点。4. 主要模块实现FormMain 与 TcpAppServer 的关键动作4.1 TcpAppServer监听与连接管理TcpAppServer 是这个工具的网络核心。它的职责按顺序是端到端监听、接受客户端连接、为每个客户端建立目标连接、维护双向转发。代码结构上它至少包含一个TcpListener、一个接收客户端连接的循环、以及一套管理客户端会话的集合。我见过很多类似的转发工具把监听和转发逻辑全部塞进 FormMain 里结果界面一卡网络也卡。TcpTunel 的工程把 TcpAppServer 单独拆出来界面层只调用它的 Start/Stop 方法这种分层在调试网络问题时非常舒服。如果你要改代码建议也保持这个边界FormMain 不直接操作 Socket。监听部分的常见实现是这样的public void Start(int listenPort) { _listener new TcpListener(IPAddress.Any, listenPort); _listener.Start(); _isRunning true; // 用独立线程接收客户端避免阻塞 UI _acceptThread new Thread(AcceptLoop); _acceptThread.IsBackground true; _acceptThread.Start(); } private void AcceptLoop() { while (_isRunning) { try { TcpClient client _listener.AcceptTcpClient(); // 每个客户端创建一个会话会话内部建立目标连接 CreateSession(client); } catch (SocketException ex) { // 监听被停止时 AcceptTcpClient 会抛异常这里要判断是不是主动关闭 if (_isRunning) { Console.WriteLine($[监听] 接受客户端失败: {ex.SocketErrorCode}); } } } }逻辑说明IPAddress.Any表示监听本机所有网卡包括 127.0.0.1 和局域网 IPAcceptTcpClient是阻塞方法所以必须放在后台线程里否则 WinForm 界面会卡死CreateSession负责为这个客户端创建目标连接每个客户端独立客户端断开不会影响其他客户端。参数上要注意AcceptTcpClient只能捕获SocketException如果TcpListener.Start()就失败了比如端口被占用会抛出SocketException的AddressAlreadyInUse这个要在 Start 方法里捕获并向上抛到 FormMain 弹窗提示。另外线程用IsBackground true是个好习惯这样主窗口关闭时后台线程会自动结束不用手动 Abort。4.2 FormMain界面启动、停止与异常反馈FormMain 负责读取配置文件、启动和停止 TcpAppServer、把监听状态和连接数量显示到界面上。正常流程是这样的窗体加载时读 config.txt解析出监听端口和目标列表点击“启动”按钮后调用 TcpAppServer.StartTcpAppServer 报错时FormMain 捕获异常并用 MessageBox 展示。界面上的状态显示通常是一个 Label 加一个按钮。启动成功后按钮文字变成“停止”Label 显示“监听 8005转发到 2 个目标”。如果你希望在界面看到实时的连接数、转发字节数那要自己在 TcpAppServer 里暴露事件。原工程有没有做这个我记不清了但从工程文件看FormMain 只有 Designer 里定义的常规控件没有特别复杂的仪表盘所以大概率是个简洁的启动/停止窗口。有一个细节值得注意FormMain 里如果用了async/await调 Stop要注意 Stop 方法里不能直接Thread.Abort()。正确做法是设置_isRunning false然后调用_listener.Stop()让 AcceptLoop 里的AcceptTcpClient抛异常退出。如果线程卡在某个客户端的接收循环里还要先关闭所有客户端连接这样接收循环才会退出。这里的顺序反了会出现“界面停止成功了但端口还占着”的情况。4.3 数据转发的核心循环与缓冲处理双向转发的核心循环是每个目标连接一个线程主客户端一个线程。主客户端线程的职责是从客户端接收数据然后把它写入所有目标连接。目标连接线程的职责是从目标服务器接收数据写入客户端连接。下面是我按常见实现还原的一个目标连接接收循环private void TargetReceiveLoop(TcpClient target, TcpClient client) { byte[] buffer new byte[8192]; NetworkStream targetStream target.GetStream(); NetworkStream clientStream client.GetStream(); try { while (_isRunning target.Connected client.Connected) { int bytesRead targetStream.Read(buffer, 0, buffer.Length); if (bytesRead 0) { // 对端关闭连接 break; } clientStream.Write(buffer, 0, bytesRead); clientStream.Flush(); } } catch (IOException ex) { // 连接被重置或断开记录后退出 Console.WriteLine($[转发] 目标连接异常: {ex.Message}); } finally { target.Close(); } }逻辑说明Read是阻塞调用读到 0 字节表示对端正常关闭写到客户端时注意要Flush否则数据可能滞留在缓冲区buffer大小 8192 是常见折中值既能容纳大部分协议的单个报文又不会占用太多内存。这个循环没有做粘包处理因为转发工具的定位是“透明传输”它不关心应用层协议原始字节是什么就转发什么。我把这个循环单独拿出来说是想强调一个边界转发工具不等于协议解析工具。它不会帮你把两个半包拼成一个整包也不会帮你拆包。TCP 本身就是流你发 200 字节可能分成两次到达也可能三个包合并成一次到达。如果你的下游服务端依赖完整报文边界那应该在应用层处理粘包而不是让转发工具来拆。这一点对拿这个工具做协议调试的人尤其重要。5. 避坑指南端口占用、线程泄漏、粘包与配置解析5.1 端口被占用启动报错后的快速定位现象点击启动后界面没有任何反应过一会儿弹出一个 SocketException或者直接崩溃。命令行里再试一次启动提示AddressAlreadyInUse。原因8005 端口已经被其他程序占用。常见的有上一次运行工具没有完全退出、别的调试工具占用了同一个端口、Windows 系统服务也偶尔会占端口。解决先用命令查端口占用netstat -ano | findstr 8005找到 PID再用tasklist /FI PID eq 进程号看是哪个程序。如果是上次的残留进程taskkill /PID 进程号 /F结束掉。关键是查清楚占用者再做决定不要随手杀掉系统服务。另外启动监听前可以在代码里做一次端口可用性预检用TcpListener尝试绑定失败就提前弹窗。5.2 客户端频繁断开导致线程越积越多现象工具运行一天后任务管理器里看进程线程数越来越多内存也不断上涨而且新客户端连接变慢甚至连不上。原因每次 Accept 到客户端都会创建一个会话会话里又为目标连接创建接收线程。如果客户端连接后没有正常退出比如直接拔网线或者程序强杀Read不会立刻返回线程就卡在那里。旧会话没清理新会话还在创建线程就泄漏了。解决给Read设置超时client.Client.ReceiveTimeout 30000这样 30 秒没有数据就抛 IOException线程退出。更稳妥的做法是单独开一个后台“巡检线程”定期检查每个客户端和目标的Connected状态以及最后的读写时间超过阈值就主动关闭连接。原工程里可能没做这么细但这是长期挂机的关键拿到代码后建议自己补。5.3 配置文件用错分隔符导致目标全部失效现象配置文件写了8005-127.0.0.1:8003|127.0.0.1:8004启动后监听正常但数据只转发到了一个目标或者一个都发不出去。原因这个工具统一用-做段分隔用:做主机端口分隔。有人在其他项目里习惯了用|或,改配置文件时顺手就用上了。解析器不认识|会把127.0.0.1:8003|127.0.0.1:8004当成一个完整段其中包含:所以被当作合法目标但端口部分是8003|127.0.0.1:8004int.Parse失败最终这个目标被丢弃。解决严格按照-和:来写不要混用。如果工具支持注释行建议在 config.txt 头部写一条注释把分隔符规则写清楚。另外解析代码里最好给每个段做 TryParse解析失败时日志里输出原始段内容方便定位。5.4 域名目标偶尔失败DNS 解析与重连策略现象目标地址写的www.code-xxx.cn:8006刚启动时一切正常跑了几个小时之后某个目标的数据突然断了但其他目标还好。原因工具只在建立连接时做一次 DNS 解析之后一直复用同一个 IP。目标服务域名解析到的新 IP 变更后旧连接可能超时或被服务端断开。另外目标服务重启后旧连接进入半开状态Connected属性可能还是 true但实际已经不能收发数据。解决在目标接收循环里捕获到 IOException 后做一次重连重连前重新解析域名。如果重连频繁失败可以做指数退避比如第一次等 1 秒第二次等 2 秒最多等 30 秒。简单一点的做法是每天凌晨定时重建所有目标连接避开业务高峰代码量也不大。5.5 大包粘包转发前要不要拆包重组现象客户端发来一个 1MB 的报文目标服务器收到的数据被分成好几段而且每段到达的时间和原始发送不完全一致。原因TCP 是流协议大数据包在传输层会被分段接收方调用Read时拿到的可能是半包也可能是一整包加上后半包。这个工具是直接转发不做粘包拆包所以下游必须自己处理。解决分两层处理。应用层协议如果自带长度字段建议下游服务先解析长度再按长度读完整报文如果协议没有长度字段那就在转发工具入口做一个可配置的“包分隔模式”比如遇到特定字节0x0A 0x0D才认为一个包结束但这种模式只能针对固定协议。通用做法是保持透明转发接收端自己处理。做联调时在工具里加一个逐字节 Hex 日志开关把收到的数据打印成十六进制字符串能有效判断是粘包还是上游本来就发的多个包。6. 验证方法与进阶玩法用现成工具测通后再改代码拿到资源后第一步不是改代码而是先按原样跑通。改 config.txt 里的监听端口为 8005目标写成本机两个不冲突的端口比如 9001 和 9002。然后在两个目标端口上分别挂两个简单的监听器最方便的是用nc命令nc -l -p 9001 nc -l -p 9002再开一个终端连接工具的 8005 端口nc 127.0.0.1 8005在 nc 里输入一行文字按回车。如果 9001 和 9002 的 nc 窗口同时收到这行文字说明主链路通了。回程测试反过来在 9001 的 nc 窗口输入一行文字8005 的 nc 窗口应该也能收到。这组测试可以证明双向转发成立。验证通过后再谈改代码。我最推荐加的第一个功能是“日志面板”。在 FormMain 里加一个多行 TextBoxTcpAppServer 转发时触发一个事件把收发方向、源端口、字节数写进去。注意 TextBox 更新要用Invoke否则跨线程操作控件会抛异常。第二个值得加的功能是按目标启用/停用在配置文件里支持在目标前加#注释解析时自动跳过这样临时不想发到某个目标时不用改端口号重启。最后一个建议是给每个连接对象加一个LastActiveTime属性每收到数据就刷新一次。之后写一个巡检线程每 30 秒扫一遍所有连接超过 5 分钟没有活动的目标连接主动关闭并重连。我做过的类似转发工具里弱点几乎都出在“连接看似活着其实已经死了”加了巡检之后挂机一个礼拜再没出过问题。从那以后我每次写转发工具都强制先做连接健康检查和线程清理再谈转发功能。希望这份 TcpTunel 资源能帮你少踩几个同样的坑。本文还有配套的精品资源点击获取