最近在使用一個文件上傳組件。發現在上傳文件時出現了以下問題：
1.文件上傳文本類型的文件，txt,xml 等類型是正常的。
2.媒體類型文件上傳會出現異常。異常如下：
[WARN] 2018-10-22 14:33:00 390 - Unable to parse request org.apache.commons.fileupload.FileUploadException: Connection reset at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:362) at org.apache.struts2.dispatcher.multipart.JakartaMultiPartRequest.parseRequest(JakartaMultiPartRequest.java:192) at org.apache.struts2.dispatcher.multipart.JakartaMultiPartRequest.processUpload(JakartaMultiPartRequest.java:131) at org.apache.struts2.dispatcher.multipart.JakartaMultiPartRequest.parse(JakartaMultiPartRequest.java:92) at org.apache.struts2.dispatcher.multipart.MultiPartRequestWrapper.<init>(MultiPartRequestWrapper.java:84) at org.apache.struts2.dispatcher.Dispatcher.wrapRequest(Dispatcher.java:849)
Caused by: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:196) at java.net.SocketInputStream.read(SocketInputStream.java:122) at org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:756)
這個問題在測試環境中沒有出現，各種文件類型上傳正常。但是到了正式環境就出問題。經過很長時間的調試（遠程調試），發現代碼執行的時候沒有進到action類就會直接報錯。各種測試，仍然找不到問題的根源。
然后在搜索的時候發現了各種類似的問題:
1.有的是上傳文件太大，觸發了tomcat上傳限制。上傳文件大小不是問題，主要是文件類型的問題。
2.重復請求導致連接重置。排查了連接情況，不屬於這種情況。
3.在環境中，上傳文件時需要先生成臨時文件，如果臨時文件夾在服務器中沒有權限，創建臨時文件失敗會導致上傳文件失敗。排除，在服務器中，整個tomcat文件夾和其子目錄都有權限。而默認情況下，臨時文件夾會在tomcat下的work目錄下子目錄創建臨時文件。除非特別配置了該臨時文件夾路徑，否則一般不會出現這個問題。
4.網絡問題，防火牆配置攔截資源。很有可能，然后排查目標服務器上的防火牆，沒有開啟。
一次偶然，發現該服務器上的項目一個網頁中的音頻文件播放失敗，播放時阻塞，瀏覽器調試窗沒有報錯。發現瀏覽器加載該資源成功，就是不能播放。抓包發現連接有問題。
只是在請求一個wav文件，但是返回的卻是文本數據。而且連接也是會復位。更加確定是被攔截了。最后發現是公司網絡對音頻網絡資源進行了攔截。可能是為了不讓你上班看視頻，聽音樂吧。使用手機熱點進行訪問服務器並上傳文件，正常使用。這解釋了為什么測試環境沒有問題，因為公司內部網絡不會進行攔截。
總結，當connect reset出現，可以通過切換網絡訪問測試，看是否有防火牆攔截問題。