使用Multipart/Form-data POST XML时遇连接意外关闭问题求助

这种The underlying connection was closed: The connection was closed unexpectedly错误通常涉及请求格式、认证、网络或服务器配置问题，我给你几个具体的排查方向：

1. 验证Basic Authentication凭证的正确性 #

• 先确认用户名和密码没有拼写错误，尤其是包含特殊字符时，要确保Base64编码的凭证格式正确（Basic Auth的凭证是用户名:密码的Base64字符串）。
• 可以先用curl做快速测试，排除凭证问题：

  curl -u your-username:your-password -F "xmlinfo=@test-small.xml" https://your-target-server-url
  

  如果curl能正常响应，那问题大概率出在你的代码实现上；如果curl也报错，那可能是服务器端的认证配置或网络问题。

2. 检查multipart/form-data请求的格式合法性 #

• 确保请求的boundary参数正确生成，没有格式错误（边界字符串不能出现在XML内容里）。
• 确认xmlinfo参数的封装格式：
  • 如果是上传XML文件，要在Content-Disposition里指定filename，同时设置Content-Type: application/xml；
  • 如果是直接传递XML字符串，也要明确Content-Disposition: form-data; name="xmlinfo"，并确保XML内容没有被意外截断或转义。

3. 排查SSL/TLS兼容性问题（如果使用HTTPS） #

• 很多连接意外关闭的问题是因为客户端和服务器的TLS版本不兼容，比如服务器只支持TLS 1.2+，但你的客户端默认使用了旧版本（如TLS 1.0）。
• 如果是.NET项目，可以在请求前强制指定TLS版本：

  ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls13;
  

4. 检查请求大小是否超出服务器限制 #

• 部分服务器会限制multipart请求的最大大小，如果你的XML内容过大，服务器可能会直接断开连接。
• 先尝试传递一个极小的XML片段（比如只包含根节点），如果能成功，就说明是请求大小的问题，需要调整服务器的配置（比如Nginx的client_max_body_size，或IIS的请求限制）。

5. 排除网络层面的拦截 #

• 检查是否有公司防火墙、代理服务器拦截了请求，这类设备有时会对multipart格式的请求做额外校验，导致连接被中断。
• 可以尝试在服务器所在的局域网内测试请求，或者关闭本地代理后重试，排除网络路由问题。

内容的提问来源于stack exchange，提问作者Frinavale