仅当移动客户端从沃达丰网络+谷歌浏览器浏览时,HTTP连接超时 [英] Http Connection Timeout only when mobile client surfing from vodafone network + google chrome

查看:98
本文介绍了仅当移动客户端从沃达丰网络+谷歌浏览器浏览时,HTTP连接超时的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆