手册页socat指出socat 是一个基于命令行的实用程序，它建立两个双向字节流并在它们之间传输数据。基于此，你的论点的顺序并不重要，我经常在不同的来源上读到相同的内容。
但有时我觉得顺序确实很重要。例如：在客户网络上，我有一个可以通过 SSH 访问的嵌入式系统。该嵌入式可以直接访问 MS SQL 数据库。当我想调试数据库中的某些内容时，我想使用在我的主机上的 VirtualBox VM 上运行的 Azure Data Studio（IP 192.168.100.1）。所以简单的ssh -L1433:dbserver:1433没有帮助。这就是我使用 socat 的地方。
首先，我使用本地转发并将目标端口 1433 连接到我的本地端口 11433
ssh my-remote-embedded -N -L11433:dbserver:1433
然后我使用socat在端口 11433 和绑定到 0.0.0.0 的 1433 之间创建直接连接，以便可以在虚拟机中访问该端口。
如果我这样做：
socat -v tcp:localhost:11433 tcp-listen:1433,bind=0.0.0.0,fork,reuseaddr
然后Azure Data Studio尝试连接到192.168.100.1:1433，但连接可以工作，但实际上并非如此。 Azure Data Studio确实可以连接（感谢
-v我可以在socat输出上看到字节在两个方向流动的选项）并且我的连接图标变成绿色，但它无法获取数据库列表，并且常规查询也不起作用。
但是，如果我将 socat 调用的顺序交换为：
socat -v tcp-listen:1433,bind=0.0.0.0,fork,reuseaddr tcp:localhost:11433
然后，Azure Data Studio 在重新启动后立即连接并毫无问题地获取数据库列表，我的查询可以正常工作。
如果关闭 Azure Data Studio 并使用交换的参数重新启动 socat，则会再次发生这种情况：连接几乎无法工作。
所以看来 socat 的参数顺序做真的很重要。我疯了吗？我在这里缺少什么？
我知道在https://learn.microsoft.com/en-us/azure-data-studio/download-azure-data-studio?tabs=win-install%2Cwin-user-install%2Credhat-install%2Cwindows-uninstall%2Credhat-卸载#install-azure-data-studio有linux的安装指南。我的问题不是关于这个，而是关于 socat，这只是一个我每次都可以重现行为的例子。
答案1
你注意到，
你的论点的顺序并不重要，我经常在不同的来源上读到相同的内容
socat有趣的是， ( )的文档可能man socat不同意：
在打开阶段，socat 打开第一个地址，然后打开第二个地址。这些步骤通常是阻塞的；因此，特别是对于像袜子这样的复杂地址类型，连接请求或身份验证对话必须在下一步开始之前完成。
这至少可以解释您所看到的一些行为。理想情况下，在尝试连接到远程服务之前，应该先连接到侦听套接字。否则，如果在本地套接字上发出连接请求之前连接到远程服务，则远程端可能会出现空闲超时。
先本地，后远程：
socat -v tcp-listen:1433,bind=0.0.0.0,fork,reuseaddr tcp:localhost:11433 # Yes先远程，再本地：
socat -v tcp:localhost:11433 tcp-listen:1433,bind=0.0.0.0,fork,reuseaddr # No