我们遇到了与此非常相似的问题：
有个人无法通过其移动运营商的网络访问我们的平台。域名如下（不是真实的）：
api.example.co.uk
auth.example.co.uk
admin.example.co.uk
最初，我们认为存在 DNS 问题，但通过将他的手机用作 wifi 热点进行调试，我们可以 ping 上面的子域，并且我们能够通过端口 80 访问平台（我们可以看到重定向到端口 443）。当我们尝试通过 IP 访问其中一个时（https://ip_地址）我们根本无法访问它，服务器上也没有日志，这意味着这不是 DNS 问题，也许是与 SSL 有关的问题。顺便说一句，公司里还有另外两个人从未遇到过这个问题，他们使用相同的移动运营商。这个假设正确吗？
我们正在使用 AWS 经典负载均衡器，并且已从 GoDaddy 获得 SSL 证书。还有其他人遇到过类似的事情吗？
更新 1
下面您可以找到来自正常网络和故障网络的针对端口 443 和端口 80 的跟踪路由：
网络故障
~$ ping api.healthera.co.uk
PING api.healthera.co.uk (52.56.123.246): 56 data bytes
64 bytes from 52.56.123.246: icmp_seq=0 ttl=239 time=46.971 ms
64 bytes from 52.56.123.246: icmp_seq=1 ttl=239 time=54.086 ms
64 bytes from 52.56.123.246: icmp_seq=2 ttl=239 time=57.204 ms
64 bytes from 52.56.123.246: icmp_seq=3 ttl=239 time=48.198 ms
64 bytes from 52.56.123.246: icmp_seq=4 ttl=239 time=50.836 ms
64 bytes from 52.56.123.246: icmp_seq=5 ttl=239 time=53.873 ms
64 bytes from 52.56.123.246: icmp_seq=6 ttl=239 time=49.791 ms
64 bytes from 52.56.123.246: icmp_seq=7 ttl=239 time=56.326 ms
64 bytes from 52.56.123.246: icmp_seq=8 ttl=239 time=54.950 ms
64 bytes from 52.56.123.246: icmp_seq=9 ttl=239 time=49.581 ms
64 bytes from 52.56.123.246: icmp_seq=10 ttl=239 time=48.452 ms
64 bytes from 52.56.123.246: icmp_seq=11 ttl=239 time=51.344 ms
64 bytes from 52.56.123.246: icmp_seq=12 ttl=239 time=46.008 ms
64 bytes from 52.56.123.246: icmp_seq=13 ttl=239 time=61.893 ms
64 bytes from 52.56.123.246: icmp_seq=14 ttl=239 time=65.324 ms
64 bytes from 52.56.123.246: icmp_seq=15 ttl=239 time=72.197 ms
64 bytes from 52.56.123.246: icmp_seq=16 ttl=239 time=47.076 ms
64 bytes from 52.56.123.246: icmp_seq=17 ttl=239 time=55.336 ms
64 bytes from 52.56.123.246: icmp_seq=18 ttl=239 time=51.878 ms
^C
--- api.healthera.co.uk ping statistics ---
19 packets transmitted, 19 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 46.008/53.754/72.197/6.583 ms
~$ dig api.healthera.co.uk +trace
; <<>> DiG 9.8.3-P1 <<>> api.healthera.co.uk +trace
;; global options: +cmd
. 263795 IN NS f.root-servers.net.
. 263795 IN NS j.root-servers.net.
. 263795 IN NS k.root-servers.net.
. 263795 IN NS b.root-servers.net.
. 263795 IN NS c.root-servers.net.
. 263795 IN NS e.root-servers.net.
. 263795 IN NS d.root-servers.net.
. 263795 IN NS a.root-servers.net.
. 263795 IN NS h.root-servers.net.
. 263795 IN NS m.root-servers.net.
. 263795 IN NS i.root-servers.net.
. 263795 IN NS l.root-servers.net.
. 263795 IN NS g.root-servers.net.
;; Received 228 bytes from 172.20.10.1#53(172.20.10.1) in 12 ms
uk. 172800 IN NS nsa.nic.uk.
uk. 172800 IN NS nsb.nic.uk.
uk. 172800 IN NS nsc.nic.uk.
uk. 172800 IN NS nsd.nic.uk.
uk. 172800 IN NS dns1.nic.uk.
uk. 172800 IN NS dns2.nic.uk.
uk. 172800 IN NS dns3.nic.uk.
uk. 172800 IN NS dns4.nic.uk.
;; Received 457 bytes from 192.58.128.30#53(192.58.128.30) in 200 ms
healthera.co.uk. 172800 IN NS ns-1976.awsdns-55.co.uk.
healthera.co.uk. 172800 IN NS ns-704.awsdns-24.net.
healthera.co.uk. 172800 IN NS ns-1098.awsdns-09.org.
healthera.co.uk. 172800 IN NS ns-251.awsdns-31.com.
;; Received 172 bytes from 156.154.100.3#53(156.154.100.3) in 67 ms
api.healthera.co.uk. 60 IN A 52.56.65.26
api.healthera.co.uk. 60 IN A 52.56.123.246
healthera.co.uk. 900 IN NS ns-1098.awsdns-09.org.
healthera.co.uk. 900 IN NS ns-1976.awsdns-55.co.uk.
healthera.co.uk. 900 IN NS ns-251.awsdns-31.com.
healthera.co.uk. 900 IN NS ns-704.awsdns-24.net.
;; Received 204 bytes from 205.251.196.74#53(205.251.196.74) in 69 ms
~$ sudo tcptraceroute api.healthera.co.uk 80
Selected device en0, address 172.20.10.5, port 55237 for outgoing packets
Tracing the path to api.healthera.co.uk (52.56.123.246) on TCP port 80 (http), 30 hops max
1 172.20.10.1 5.244 ms 8.540 ms 10.747 ms
2 * * *
3 172.23.128.201 62.617 ms 38.532 ms 48.225 ms
4 * * *
5 188.31.253.50.threembb.co.uk (188.31.253.50) 46.400 ms 40.852 ms 47.852 ms
6 188.31.255.77.threembb.co.uk (188.31.255.77) 39.116 ms 50.442 ms 46.770 ms
7 188.31.255.161.threembb.co.uk (188.31.255.161) 47.963 ms 52.674 ms 47.617 ms
8 188.31.255.126.threembb.co.uk (188.31.255.126) 52.529 ms 47.936 ms 40.104 ms
9 188.31.255.157.threembb.co.uk (188.31.255.157) 51.766 ms 47.328 ms 47.880 ms
10 188.31.255.170.threembb.co.uk (188.31.255.170) 51.930 ms 51.522 ms 47.873 ms
11 195.66.237.175 51.970 ms 61.656 ms 52.034 ms
12 * * *
13 * * *
14 52.94.35.92 56.130 ms 66.108 ms 54.347 ms
15 52.94.33.185 47.736 ms 54.679 ms 59.655 ms
16 52.94.33.48 60.349 ms 59.425 ms 59.818 ms
17 * * *
18 * * *
19 * * *
20 ec2-52-56-123-246.eu-west-2.compute.amazonaws.com (52.56.123.246) [open] 47.924 ms 41.583 ms 45.531 ms
~$ sudo tcptraceroute api.healthera.co.uk 443
Selected device en0, address 172.20.10.5, port 55241 for outgoing packets
Tracing the path to api.healthera.co.uk (52.56.123.246) on TCP port 443 (https), 30 hops max
1 172.20.10.1 3.697 ms 3.892 ms 5.801 ms
2 * * *
3 172.23.128.201 55.388 ms 42.007 ms 48.522 ms
4 * * *
5 188.31.253.50.threembb.co.uk (188.31.253.50) 49.337 ms 51.717 ms 39.670 ms
6 188.31.255.77.threembb.co.uk (188.31.255.77) 52.875 ms 40.477 ms 43.492 ms
7 188.31.255.166.threembb.co.uk (188.31.255.166) 40.851 ms 50.530 ms 48.073 ms
8 188.31.255.117.threembb.co.uk (188.31.255.117) 116.008 ms 35.044 ms 47.981 ms
9 188.31.255.154.threembb.co.uk (188.31.255.154) 56.149 ms 45.818 ms 52.129 ms
10 188.31.255.170.threembb.co.uk (188.31.255.170) 51.710 ms 46.975 ms 51.461 ms
11 195.66.237.175 48.861 ms 58.403 ms 58.259 ms
12 * * *
13 * * *
14 52.94.35.104 58.779 ms 44.056 ms 58.556 ms
15 52.94.33.189 416.028 ms 50.189 ms 51.591 ms
16 52.94.33.48 47.965 ms 52.498 ms 58.664 ms
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
Destination not reached
工作网络
~$ tcptraceroute api.healthera.co.uk 443
Selected device eth0, address 192.168.8.12, port 39878 for outgoing packets
Tracing the path to api.healthera.co.uk (52.56.65.26) on TCP port 443 (https), 30 hops max
1 192.168.8.1 1.382 ms 0.690 ms 0.594 ms
2 host90-152-126-145.ipv4.regusnet.com (90.152.126.145) 0.475 ms 0.580 ms 0.547 ms
3 ga013c-the-count.access.colt.net (195.110.85.97) 9.519 ms 9.311 ms 9.240 ms
4 ir3.fra.router.colt.net (212.74.76.181) 12.805 ms 9.735 ms 9.912 ms
5 195.66.237.175 10.861 ms 10.541 ms 25.791 ms
6 * * *
7 * * *
8 52.94.35.88 18.515 ms 20.163 ms 18.888 ms
9 52.94.33.201 12.063 ms 11.593 ms 11.549 ms
10 52.94.33.78 12.014 ms 12.839 ms 11.568 ms
11 * * *
12 * * *
13 * * *
14 ec2-52-56-65-26.eu-west-2.compute.amazonaws.com (52.56.65.26) [open] 11.491 ms 12.290 ms 12.069 ms
~$ tcptraceroute api.healthera.co.uk 80
Selected device eth0, address 192.168.8.12, port 36500 for outgoing packets
Tracing the path to api.healthera.co.uk (52.56.123.246) on TCP port 80 (http), 30 hops max
1 192.168.8.1 1.390 ms 0.581 ms 0.594 ms
2 host90-152-126-145.ipv4.regusnet.com (90.152.126.145) 0.398 ms 0.404 ms 0.356 ms
3 ga013c-the-count.access.colt.net (195.110.85.97) 9.241 ms 19.771 ms 9.237 ms
4 xe0-0-7-pr2.lon.router.colt.net (212.74.72.117) 9.592 ms 10.360 ms 9.498 ms
5 195.66.237.175 10.776 ms 10.595 ms 10.505 ms
6 * * *
7 * * *
8 52.94.35.80 16.369 ms 27.377 ms 13.743 ms
9 52.94.33.183 11.516 ms 10.957 ms 10.937 ms
10 52.94.33.52 10.903 ms 11.148 ms 11.598 ms
11 * * *
12 * * *
13 * * *
14 ec2-52-56-123-246.eu-west-2.compute.amazonaws.com (52.56.123.246) [open] 14.278 ms 13.619 ms 12.170 ms
~$ dig api.healthera.co.uk +trace
; <<>> DiG 9.9.5-3ubuntu0.15-Ubuntu <<>> api.healthera.co.uk +trace
;; global options: +cmd
. 3600 IN NS b.root-servers.net.
. 3600 IN NS c.root-servers.net.
. 3600 IN NS d.root-servers.net.
. 3600 IN NS e.root-servers.net.
. 3600 IN NS f.root-servers.net.
. 3600 IN NS g.root-servers.net.
. 3600 IN NS h.root-servers.net.
. 3600 IN NS i.root-servers.net.
. 3600 IN NS j.root-servers.net.
. 3600 IN NS k.root-servers.net.
. 3600 IN NS l.root-servers.net.
. 3600 IN NS m.root-servers.net.
. 3600 IN NS a.root-servers.net.
;; Received 460 bytes from 127.0.1.1#53(127.0.1.1) in 463 ms
uk. 172800 IN NS nsa.nic.uk.
uk. 172800 IN NS nsb.nic.uk.
uk. 172800 IN NS nsc.nic.uk.
uk. 172800 IN NS nsd.nic.uk.
uk. 172800 IN NS dns1.nic.uk.
uk. 172800 IN NS dns2.nic.uk.
uk. 172800 IN NS dns3.nic.uk.
uk. 172800 IN NS dns4.nic.uk.
uk. 86400 IN DS 43876 8 2 A107ED2AC1BD14D924173BC7E827A1153582072394F9272BA37E2353 BC659603
uk. 86400 IN RRSIG DS 8 1 86400 20171004170000 20170921160000 15768 . ZKjCYbJffsP8fYzMOeeYFj4+w+bE12NTYgD0zM98ppT4ZbkS/nzESoIA bJ35XHTWBR1aZlsDlDE8ynIiy3Tp0xN6NvXrIE5iYwitwvR8RCOKyBZk R9eopH/6h5ZX0DhfgaQdgIhtdmokr63ZYfU+oFxdBJ9fa7NihVVRAdJ4 9/Y9UM0sxhUf6usgdg3iagY7iCYSz3XLZD0vk8i7F2fls+dweGTv7IZT cr/EHD7riuMiq82KPjhYmuJJVf2Y1AABZpD7Tl1p5K7lUkBDc9pgtMs9 j4eYeuoBr4GqW8C3bGnVF5fyJAqFYP+wCjvcLP4BbOwCAvafrwyWezuU ajpHcg==
;; Received 803 bytes from 193.0.14.129#53(k.root-servers.net) in 304 ms
healthera.co.uk. 172800 IN NS ns-1098.awsdns-09.org.
healthera.co.uk. 172800 IN NS ns-704.awsdns-24.net.
healthera.co.uk. 172800 IN NS ns-251.awsdns-31.com.
healthera.co.uk. 172800 IN NS ns-1976.awsdns-55.co.uk.
G9F1KIIHM8M9VHJK7LRVETBQCEOGJIQP.co.uk. 10800 IN NSEC3 1 1 0 - G9HKV8PHGJ1NMH94L9RMIQM0J64UCIPK NS SOA RRSIG DNSKEY NSEC3PARAM TYPE65534
G9F1KIIHM8M9VHJK7LRVETBQCEOGJIQP.co.uk. 10800 IN RRSIG NSEC3 8 3 10800 20171027064114 20170922060233 33621 co.uk. olk2vORgfr0jK+4kQpMcrvcvpB66fnaci6fE2+gHuDGUSgZu+IVUwCIO LLRV3UNu7fVJtc9gHUc2u2pSHBjBzqYIJ9g5ltHyUzQjQ0u1jdFUJs46 f8ay+aKDI4lydiGR+guCsweqjDlo7glFsIujf3h8HV2IaWNH5Cc6l/vN StQ=
5LKTI0UUB0BVT731FML5I9G32RGVK6B0.co.uk. 10800 IN NSEC3 1 1 0 - 5LM4S3GU530RJOS0G7PK5K90UEDRP3AP NS DS RRSIG
5LKTI0UUB0BVT731FML5I9G32RGVK6B0.co.uk. 10800 IN RRSIG NSEC3 8 3 10800 20171027091222 20170922081222 33621 co.uk. rRjUh0kmlq+IiXlxdHOqJzSChhtyMGiawzSsHsdOAJvb0N7EJqMd5RwZ pCcVpY79BPiY+GCmDZR974FP7kleDkh5laGXKKwDfeO1BDnQNXBT3Ldx YJseNQYwSGAT2QeyLAtQltYmRBup1mn6pUcekRAQQgrzjM6rjXMkG7/B L9U=
;; Received 706 bytes from 156.154.103.3#53(nsd.nic.uk) in 188 ms
api.healthera.co.uk. 60 IN A 52.56.123.246
api.healthera.co.uk. 60 IN A 52.56.65.26
healthera.co.uk. 900 IN NS ns-1098.awsdns-09.org.
healthera.co.uk. 900 IN NS ns-1976.awsdns-55.co.uk.
healthera.co.uk. 900 IN NS ns-251.awsdns-31.com.
healthera.co.uk. 900 IN NS ns-704.awsdns-24.net.
;; Received 215 bytes from 205.251.192.251#53(ns-251.awsdns-31.com) in 331 ms
更新2
另一件有趣的事情是，当我们处于“损坏”的网络上时，端口 443 似乎被阻止了：
~$ nmap -p 443 api.healthera.co.uk
Starting Nmap 7.60 ( https://nmap.org ) at 2017-09-22 12:07 BST
Nmap scan report for api.healthera.co.uk (52.56.123.246)
Host is up (0.064s latency).
Other addresses for api.healthera.co.uk (not scanned): 52.56.65.26
rDNS record for 52.56.123.246: ec2-52-56-123-246.eu-west-2.compute.amazonaws.com
PORT STATE SERVICE
443/tcp filtered https
Nmap done: 1 IP address (1 host up) scanned in 0.76 seconds
~$ nmap -p 80 api.healthera.co.uk
Starting Nmap 7.60 ( https://nmap.org ) at 2017-09-22 12:07 BST
Nmap scan report for api.healthera.co.uk (52.56.123.246)
Host is up (0.077s latency).
Other addresses for api.healthera.co.uk (not scanned): 52.56.65.26
rDNS record for 52.56.123.246: ec2-52-56-123-246.eu-west-2.compute.amazonaws.com
PORT STATE SERVICE
80/tcp open http
Nmap done: 1 IP address (1 host up) scanned in 0.19 seconds
相反，在正常运行的网络上，端口 443 似乎开放
$ nmap -p 80 api.healthera.co.uk
Starting Nmap 7.01 ( https://nmap.org ) at 2017-09-22 12:11 BST
Nmap scan report for api.healthera.co.uk (52.56.123.246)
Host is up (0.011s latency).
Other addresses for api.healthera.co.uk (not scanned): 52.56.65.26
rDNS record for 52.56.123.246: ec2-52-56-123-246.eu-west-2.compute.amazonaws.com
PORT STATE SERVICE
80/tcp open http
Nmap done: 1 IP address (1 host up) scanned in 0.15 seconds
$ nmap -p 443 api.healthera.co.uk
Starting Nmap 7.01 ( https://nmap.org ) at 2017-09-22 12:11 BST
Nmap scan report for api.healthera.co.uk (52.56.65.26)
Host is up (0.013s latency).
Other addresses for api.healthera.co.uk (not scanned): 52.56.123.246
rDNS record for 52.56.65.26: ec2-52-56-65-26.eu-west-2.compute.amazonaws.com
PORT STATE SERVICE
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 0.09 seconds
答案1
问题解决了，它太愚蠢了 - 至少我学到了更多关于网络层、SSL 证书和防火墙的知识。
所以问题是：
VPC - 网络 ACL - 入站规则，然后仅针对端口 443 拒绝整个 IP 子范围。
很抱歉浪费了您的时间，并感谢您的真正有用的意见。
答案2
我为一家大型 SSL 证书颁发机构工作，根据我的经验，这些情况下的问题一般是移动设备上的浏览器/密钥库已过期。很可能该设备未安装最新版本的 Android 或 iOS，并且新发布的根证书颁发机构不受该客户端信任。
在这些情况下，根证书颁发机构通常已发布了新的签名证书，或者他们是一个全新的证书颁发机构，他们将使用旧证书签署新的签名证书，或者让现有（和竞争）证书颁发机构签署其证书。
例如，对于现有的签名机构来说，这可能是因为他们正在提高加密级别 -例如，如果他们过去使用 1024 位签名证书签署证书，而现在已经改为 2048 位。如果您使用的移动设备的操作系统是在 2048 位证书发布之前编译和发布的，则其已知和受信任的根证书包中没有新证书。您需要一种方法来向操作系统发出信号，表示它应该信任新的根签名机构。
这就是中介证书或者链式证书。通过包含链式证书，您应该能够使用旧设备已经信任的证书来表明它尚不知道的新证书也可以信任以验证 SSL。如果您可以提供一些有关签署证书的 CA 和您正在使用的移动设备版本的详细信息，这里可能会为您提供更详细的答案，但作为一般概述，这是最可能的问题。
答案3
您可以使用 tcptraceroute 来猜测端口 443 被阻止的位置。
tcptraceroute 52.56.123.246 443
应该会给你防火墙的 IP 地址，该防火墙阻止对端口 443 的请求
答案4
测试你的 SSLhttps://www.ssllabs.com/ssltest/确保你得到“A”，如果没有，那么证书就有问题。很可能需要 2048 位加密。但事实上，你使用的托管公司并不是最好的。我推荐 digital ocean。
希望这可以帮助