問題：tomcat部署javaweb項目（war包）後，啓動正常，但是項目頁面不能訪問。
環境：Linux下tomcat9.0.27。
排查：
1.首先排除啓動異常，無論是tomcat日誌還是應用自身的日誌，都沒有異常記錄；
2.然後排除端口和路徑異常，tomcat首頁（貓圖）可以正常訪問，且webapps文件夾下新建靜態資源頁面可以訪問到。但是項目頁面不能訪問，也不返回404，就是一片空白。若輸入錯誤的項目名，則會返回404；（網上多數都是這裏的問題，但我不是-_-||）
3.然後排除項目本身的異常，在其他服務器上，同版本的tomcat部署同樣的war包，啓動後可以正常訪問，且在這個訪問不了的服務器上，項目後臺一直在運行，每天設置的定時任務都可以正常執行併產生日誌。
推測：
如此看來，很可能就是目標機器的環境問題了，上過linux的都知道，這個環境要素是相當重要的，無論在上面乾點啥都敏感得一批，稍有不慎就會丟給你一堆莫名其妙、刷新你三觀的問題。既然tomcat可以正常啓動，且webapps下的純靜態資源可以訪問到，那麼，就很可能是tomcat對java資源的編譯問題了。
項目用的是jsp頁面（甲方要求的），小衆所知，tomcat上的jsp頁面，會隨着瀏覽器請求逐一編譯成java和class文件，並存放在work目錄下。查看了一下work目錄，下面有Catalina/localhost/項目名/org/apache/jsp/項目jsp資源路徑，裏面對應於所有被訪問到的jsp頁面生成了一對.java、.class文件，如index.jsp被訪問過就會有index_jsp.java和index_jsp.class這對cp，一次訪問，終身保留，以後每次光顧的都是這裏，直到資源被修改或服務重啓。沒有被請求過的資源則不會出現在這裏。
我看到的這個work目錄下，只有index.jsp被編譯進來，因爲其他的根本沒機會被請求。問題是這個index既然進來了，就表明請求已經收到，那爲何不返回給客戶端呢？洗都洗好了，不讓人碰，什麼情況？是編譯後的index異常，拿不出手？還是中間被什麼攔截了？放一個在別的地方被正常使用過的index_jsp.java和index_jsp.class來替換一下試試吧。（實際並沒有試，因爲發現問題可能不在這裏。）
（未完待續……）
書接上回……
昨天突然想到一個問題，項目的首頁jsp並沒有什麼實際內容，在被訪問到的時候，它會判斷一下當前用戶狀態，然後跳轉到其他頁面。所以，在linux上直接用curl http://....訪問，會被瞬間彈走。那麼就要加上另一個option了，這樣：curl -L http://.....，哎，這回有內容了，果然是跳轉後的頁面！那麼本地訪問是沒問題的，不信的話進到work裏面再去看看，果然又多了一對剛纔訪問到的頁面編譯後的java類文件。這時又想到另一個文件（之前就是沒關注這個，後來經人提醒纔想到。。。），tomcat/logs下面的訪問日誌“localhost_access_log.2020-06-08.txt”，這裏面存有所有成功抵達的來訪記錄，包括來訪者IP、時間、請求方式、請求資源以及返回的http狀態碼。看了下，剛纔的訪問果然有記錄：
127.0.0.1 - - [08/Jun/2020:09:37:18 +0800] "GET /xmm HTTP/1.1" 302 -
127.0.0.1 - - [08/Jun/2020:09:38:10 +0800] "GET /xmm/index.jsp HTTP/1.1" 302 -
127.0.0.1 - - [08/Jun/2020:09:47:12 +0800] "GET /xmm/ HTTP/1.1" 302 -
127.0.0.1 - - [08/Jun/2020:09:47:12 +0800] "GET /xmm/login/main.do?reqId=10010 HTTP/1.1" 302 -
127.0.0.1 - - [08/Jun/2020:09:47:12 +0800] "GET /xmm/login/login.do;jsessionid=D570B19A7F2B44C05FD425E2DD659011 HTTP/1.1" 200 10086
127.0.0.1 - - [08/Jun/2020:09:55:43 +0800] "GET / HTTP/1.1" 200 11215
那就再試試瀏覽器訪問，還是熟悉的空白頁面
再進訪問日誌，果然沒有新增任何記錄。可以確定訪問請求沒有真實抵達tomcat無疑了。之前走的都是彎路，要是早注意到這裏會節省不少時間。
確定問題：
那麼問題就在訪問過程上了。既然webapps下的純靜態html頁面是可以訪問的，那說明路本身是通的，只是因爲javaweb和jsp本身的特殊性導致請求沒進來。你看，首頁它就用了個跳轉——跳轉往往伴隨的是重定向，而重定向又跟通訊方式息息相關……哎，似乎有線索了。應該就是javaweb使用的jsp頁面重定向跳轉出了問題，但是本地可以正常跳轉（加-L），外部則進都不讓進來，那麼通訊協議就有着莫大的干係了。
解決：
現在焦點轉向服務網絡架構，這個項目部署在甲方的環境，他們採用的是內網服務器tomcat部署，外網訪問使用nginx代理轉發，且配置了SSL加密。也就是瀏覽器通過https協議，使用域名訪問nginx，nginx再通過http協議轉發給tomcat。這種方式訪問普通的前端資源或許沒問題，但是涉及到java那種老式的前後端高度耦合的jsp頁面就很有問題了。因爲不擅長這個，果斷搜尋資料，網上還是有很多人遇到過這種坑的。接下來就是按照篩選後的比較靠譜的資料各種改配置和測試，在正確配置了nginx和tomcat後，終於可以通過瀏覽器訪問了！
這裏關鍵有兩點，一是要能夠有權限配置和重啓nginx與tomcat，一是要根據自己的實際情況篩選靠譜的資料。沒有權限或者沒有管理員的現場支持，那就只能乾着急；一般的問題，網上資料形形色色，各有各的理，沒有最好的，只有最合適的。
結語
問題的排查和解決過程大體如上，因爲環境不在自己家，來來回回的費了不少時間。這種情況一般首先從自己項目找原因，然後再排查服務環境的問題，確定問題的範圍非常重要。希望能夠幫助同樣入坑的小夥伴，也希望有大神指正謬誤之處。
最後感謝這位老哥的博文：解決nginx部署https後，原tomcat部署的javaweb項目http不能正常加載js、css資源問題