SilverLight大文件上传故障：900KB以上文件多数上传失败

这问题确实有点绕——UAT正常生产抽风，还只在特定时段偶尔能成，结合你给出的信息，我从几个方向给你梳理排查点：

1. 先确认SilverLight客户端侧的限制 #

SilverLight本身有独立的上传逻辑，别只盯着服务端配置：

• 检查上传代码里有没有硬编码的文件大小阈值，比如是不是不小心把900KB设成了隐性上限？
• 查看客户端HttpWebRequest的超时设置，是不是设得太短？白天网络波动大，大文件还没传完就超时中断，这种情况服务端可能根本没收到完整请求，自然没日志；而清晨网络稳定，能在超时前完成上传。
• 有没有开启SilverLight的分块上传？一次性上传大文件容错性差，分块上传能降低网络波动带来的失败概率。

2. 深挖IIS7的隐藏配置 #

你已经检查了maxRequestLength，但IIS还有几个容易被忽略的关键设置：

• 请求筛选模块的maxAllowedContentLength：这是IIS层面的请求大小限制，单位为字节，默认值通常很小（比如30MB左右）。需要在web.config的<system.webServer><security><requestFiltering><requestLimits>节点配置，比如支持10MB就写maxAllowedContentLength="10485760"，记得两台Web服务器要同步配置！
• 开启失败请求跟踪（Failed Request Tracing）：这个功能能捕捉IIS层面的请求处理细节，比如请求是否被筛选模块拦截、有没有URL重写异常等，哪怕应用日志没记录，这里也能找到线索。
• 检查IIS的连接超时和空闲超时设置，生产环境白天流量大，会不会因为连接池耗尽导致请求被直接丢弃？

3. 排查生产环境特有差异点 #

毕竟UAT没问题，生产环境的独有配置是关键：

• 两台Web服务器的配置完全一致吗？比如SilverLight应用版本、依赖库、服务器杀毒软件/安全软件的扫描规则？会不会其中一台服务器的安全软件在白天资源紧张时，扫描上传文件导致中断，清晨扫描任务少就正常？
• 负载均衡和防火墙的动态规则：哪怕你直连了服务器，也要确认防火墙有没有动态限流/带宽整形规则？比如白天带宽占满时自动截断大文件请求，清晨带宽空闲就放行。可以让网络团队导出防火墙的流量日志，对比失败时段的拦截记录。
• 服务器资源监控：对比清晨和白天的CPU、内存、磁盘IO使用率，会不会白天磁盘IO过高，导致上传临时文件写入失败，但应用没抛出异常？

4. 补充日志和抓包定位根因 #

当前日志缺失是最大的障碍，得补上关键信息：

• 在SilverLight客户端添加日志：捕获上传过程中的WebException详细信息，包括错误码、响应内容，明确是客户端发起请求失败，还是服务端返回了未被记录的错误。
• 开启服务端详细追踪：如果是用WCF做SilverLight服务，开启WCF的追踪日志，能看到请求是否到达服务端、处理过程中有没有隐藏异常。
• 双向抓包验证：用Wireshark在客户端和服务器端同时抓包，观察上传大文件时的TCP连接状态——有没有丢包、重传，或者服务器发送RST包？这能直接区分是网络问题还是应用问题。

5. 针对“清晨成功”的特殊排查 #

这个现象提示问题和负载/时段强相关：

• 有没有定时运维任务？比如清晨服务器自动清理临时文件、重启应用池，此时资源充足，上传就成功；白天临时文件堆积、应用池内存泄漏，导致上传失败。
• 检查生产环境的网络带宽峰值，是不是白天刚好遇到带宽瓶颈，大文件上传被隐性限流？

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