仅当移动客户端从沃达丰网络+谷歌浏览器浏览时,HTTP连接超时 [英] Http Connection Timeout only when mobile client surfing from vodafone network + google chrome
问题描述
我有一个Web应用程序(spring-boot,tomcat),它可以正常工作并且可以通过https正常访问,但前提是客户端不在vodafone移动网络内并且无法使用chrome浏览. 如果是这样,Chrome浏览器在导航到该页面时会超时,并且根本无法访问该网站,而其他浏览器则可以正常访问该网站.
I have a web application (spring-boot, tomcat) which is working and reachable through https without problems, but only if the client is not inside mobile network of vodafone and browsing with chrome. If so, when navigating to the page, chrome gives a timeout and simply cannot reach the website, whereas another browser has no problems reaching the site.
一些有趣的事实可能是: -我更新到了java11,使用了acceptopenjdk v11.0.3(也许与tls 1.3有关的一些问题?) -在更新之前,它可能适用于移动网络/浏览器的所有组合 -ssl握手失败,附加了某些有时(并非总是)出现在日志中的异常. -仅在沃达丰移动网络中浏览Chrome浏览器时发生, 即使在该设备上创建热点并通过该热点与另一台设备浏览时,也无法正常工作 -证书链不完整,在 https://www.ssllabs.com 下运行的测试获得B级
Some interesting facts may be: - i updated to java11, using adoptopenjdk v11.0.3 (maybe some problems related to tls 1.3?) - before the update it was probably working with all combinations of mobile network / browser - the ssl handshake fails, some exceptions which appear sometimes (not always) in the log are attached. - happens only when browsing through chrome in vodafone mobile network, even when creating a hotspot on that device and surfing with another device through that hotspot will also not work - the certificate chain is incomplete, a test run under https://www.ssllabs.com gets a B grade.
有人也有类似的问题吗?任何想法出什么事了吗? 任何帮助都将受到高度赞赏.
Did anyone also had similar issues? Any ideas what is going wrong here? Any help is highly appreciated.
通过其ip直接浏览到该站点也无济于事.
Directly browsing to the site by its ip also didn't help.
java.util.NoSuchElementException: No value present
at java.base/java.util.Optional.get(Unknown Source) ~[na:na]
at java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(Unknown Source) ~[na:na]
at java.base/sun.security.ssl.SSLHandshake.produce(Unknown Source) ~[na:na]
at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(Unknown Source) ~[na:na]
at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(Unknown Source) ~[na:na]
at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(Unknown Source) ~[na:na]
at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(Unknown Source) ~[na:na]
at java.base/sun.security.ssl.SSLHandshake.consume(Unknown Source) ~[na:na]
at java.base/sun.security.ssl.HandshakeContext.dispatch(Unknown Source) ~[na:na]
at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(Unknown Source) ~[na:na]
at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(Unknown Source) ~[na:na]
at java.base/java.security.AccessController.doPrivileged(Native Method) ~[na:na]
at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(Unknown Source) ~[na:na]
at org.apache.tomcat.util.net.SecureNioChannel.tasks(SecureNioChannel.java:423) ~[tomcat-embed-core-9.0.19.jar!/:9.0.19]
at org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:483) ~[tomcat-embed-core-9.0.19.jar!/:9.0.19]
at org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:238) ~[tomcat-embed-core-9.0.19.jar!/:9.0.19]
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1724) ~[tomcat-embed-core-9.0.19.jar!/:9.0.19]
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) ~[tomcat-embed-core-9.0.19.jar!/:9.0.19]
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[na:na]
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) ~[na:na]
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) ~[tomcat-embed-core-9.0.19.jar!/:9.0.19]
at java.base/java.lang.Thread.run(Unknown Source) ~[na:na]
和
java.nio.BufferUnderflowException: null
at java.base/java.nio.Buffer.nextGetIndex(Unknown Source) ~[na:na]
at java.base/java.nio.HeapByteBuffer.get(Unknown Source) ~[na:na]
at java.base/sun.security.ssl.ClientHello$ClientHelloMessage.<init>(Unknown Source) ~[na:na]
at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(Unknown Source) ~[na:na]
at java.base/sun.security.ssl.SSLHandshake.consume(Unknown Source) ~[na:na]
at java.base/sun.security.ssl.HandshakeContext.dispatch(Unknown Source) ~[na:na]
at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(Unknown Source) ~[na:na]
at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(Unknown Source) ~[na:na]
at java.base/java.security.AccessController.doPrivileged(Native Method) ~[na:na]
at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(Unknown Source) ~[na:na]
at org.apache.tomcat.util.net.SecureNioChannel.tasks(SecureNioChannel.java:423) ~[tomcat-embed-core-9.0.19.jar!/:9.0.19]
at org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:483) ~[tomcat-embed-core-9.0.19.jar!/:9.0.19]
at org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:238) ~[tomcat-embed-core-9.0.19.jar!/:9.0.19]
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1724) ~[tomcat-embed-core-9.0.19.jar!/:9.0.19]
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) ~[tomcat-embed-core-9.0.19.jar!/:9.0.19]
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[na:na]
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) ~[na:na]
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) ~[tomcat-embed-core-9.0.19.jar!/:9.0.19]
at java.base/java.lang.Thread.run(Unknown Source) ~[na:na]
此外,日志中的另一条警告是关于:
Also, another warning in the logs is about:
The ClientHello was not presented in a single TLS record so no SNI information could be extracted
推荐答案
事实证明,它是提供程序(vodafone)+ tls 1.3 + java 11的组合 更改配置并再次使用tls 1.2之后,它又可以工作了. 根本没有解决办法,但是给了我们更多的时间来调查确切原因
As it turned out, it was a combination of the provider (vodafone) + tls 1.3 + java 11 After changing the config and using tls 1.2 again, it worked again. This is no fix at all, but gives us more time to investigate the exact reason
这篇关于仅当移动客户端从沃达丰网络+谷歌浏览器浏览时,HTTP连接超时的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!