I was able to successfully run the websocket in my local machine with the following apache configuration,
ProxyRequests off
ProxyPreserveHost on
<Location /chat>
ProxyPass ws://localhost:8080/chat
ProxyPassReverse ws://localhost:8080/chat
</Location>
I am using mod_proxy_wstunnel for Apache/2.4.7 (Ubuntu) and using Wildfly 9.0.1. When I moved the deployment to my production server(AWS) with the same configuration mentioned I get following response instead,
WebSocket is already in CLOSING or CLOSED state.
The Weird thing is I was actually able to connect to WebSocket from within the hosted server using wscat,
wscat -c ws://example.com/chat/1/
But, The connection from outside the server/browser results on the response I have stated above. First of all I thought that the issue was probably due to AWS filtering the Hop-by-Hop header i.e removing the Upgrade and Connection header for the websocket request. But, When I created a dummy websocket server using websocketd, I was able to fetch the result through the same URL.
I am not sure if the issue is related to the Wildfly Application server or the Apache Proxy Pass. I too tried using NGINX but I am getting the same response as using Apache. Some of the Stackoverflow post suggested on disabling the mod_reqtimeout which I have done.
The Websocket request successfully triggers @OnOpen event of Websocket and immediately closes without any significant log. Following lines of code results on 1006 which is CLOSED_ABNORMALLY.
@OnClose
public void close(Session session, CloseReason c) {
logger.info("Closing:" + c.getCloseCode());
}
Here is the Request/Response Log from Chrome Dev Tool,
General
Request URL:ws://example.com/chat/3
Request Method:GET
Status Code:101 Switching Protocols
Response Headers
Connection:Upgrade
Content-Length:0
Date:Fri, 13 May 2016 13:09:11 GMT
Origin:http://example.com
Sec-WebSocket-Accept:pPjTLv5Dz+/vyjY/SkeMihaXDd0=
Sec-WebSocket-Location:ws://example.com/chat/3
Server:WildFly/9
Upgrade:WebSocket
X-Powered-By:Undertow/1
Request Headers
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:no-cache
Connection:Upgrade
Cookie:mp_c4f10660603c33a8e9307b70e6767539_mixpanel=%7B%22distinct_id%22%3A%20%2215210855b11180-0ffdda567-1821170c-d37aa-15210855b123f2%22%2C%22%24initial_referrer%22%3A%20%22%24direct%22%2C%22%24initial_referring_domain%22%3A%20%22%24direct%22%7D; mf_user=a60cd2cdcfc41836645d949f71ee3127; intercom-id=d1af89ac-9d55-4fef-8a17-3848d8ef0fce; wooTracker=VQf16pMBx4Pu; _ga=GA1.2.544774749.1447732319; JSESSIONID=z4a1hBpQJQz4YCsLivHRRFf8b0dzYzBsT_4PLadB.ip-172-30-0-20; mf_154095de-56ef-4099-9976-f9a298cf0677=8438220eda64d856436d798ca0b9188a|05132367e34aabbf7bcce5b1e8811235b0bd15d4|1463144963483||19|
Host:example.com
Origin:http://example.com
Pragma:no-cache
Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits
Sec-WebSocket-Key:94OH1SxHvszgJO6Rg31WGA==
Sec-WebSocket-Version:13
Upgrade:websocket
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36
Please let me know if you have any ideas/suggestions regarding the subject matter.
We found a possible problem in the websocket communication between client and server: Kaspersky, and their corporative firewall.
If we disable the firewall the websocket works (websocketstest is our friend!). But this workaround it isn't a good solution, because our security guys will not be happy :).
Other problem could be the correct configuration in Apache (your configuration looks correct):
ProxyRequests off
ProxyPreserveHost on
Our approach is a secure websocket. We coded a websocket test over TLS using the echo server in the website (http://www.websocket.org/echo.html) and it worked!!!.
来源：https://stackoverflow.com/questions/37211037/wildfly-websocket-apache-websocket-is-already-in-closing-or-closed-state