☰

更新

tag-icon • tag-icon networking wireless internet connection
更新

几乎无法访问大多数知名网站（例如https://stackoverflow.com，https://github.com) 根据特定笔记本电脑的特定 Wi-Fi 网络无论使用哪种浏览器。但是，与 Google 相关的网站（例如https://google.com，https://youtube.com) 工作正常。

之前笔记本电脑使用欧洲其他 Wi-Fi 网络（机场、咖啡店、其他家庭网络等）时都没有遇到任何问题。

周围的任何其他设备（Windows 笔记本电脑、iPad、iPhone、Android 手机）使用同一个 Wi-Fi 网络显示上述任何有问题的网站都完全没有问题。

因此，看起来笔记本电脑和网络之间存在一些不一致。

设置

机器：Dell XPS-13-9360 笔记本电脑

无线适配器：

$ sudo lshw -C network
  *-network                 
       description: Wireless interface
       product: QCA6174 802.11ac Wireless Network Adapter
       vendor: Qualcomm Atheros
       physical id: 0
       bus info: pci@0000:3a:00.0
       logical name: wlp58s0
       version: 32
       serial: 9c:b6:d0:dc:58:19
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
       configuration: broadcast=yes driver=ath10k_pci driverversion=5.4.0-77-generic firmware=WLAN.RM.4.4.1-00079-QCARMSWPZ-1 ip=192.168.173.111 latency=0 link=yes multicast=yes wireless=IEEE 802.11

操作系统：

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.5 LTS
Release:    18.04
Codename:   bionic

浏览器：Firefox 89.0.2，Chrome 91.0.4472.114

互联网服务提供商： https://www.unitymedia.de/（沃达丰）

调制解调器：Compal 连接盒 CH7465LG-LC

连接类型：DSL

已执行诊断/修复

将其关闭并重新打开：

试着

  • 将调制解调器重置为出厂设置
  • 关闭调制解调器的电源，几秒钟后再打开
  • 通过管理页面禁用调制解调器的防火墙
  • 删除（忘记）笔记本电脑上的连接
  • 重新启动网络管理器

以不同的顺序多次。

ping

  • stackoverflow.com 
    $ ping stackoverflow.com
PING stackoverflow.com (151.101.1.69) 56(84) bytes of data.
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=26 ttl=59 time=1881 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=27 ttl=59 time=857 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=28 ttl=59 time=91.0 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=29 ttl=59 time=27.4 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=30 ttl=59 time=27.4 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=31 ttl=59 time=27.7 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=32 ttl=59 time=29.1 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=33 ttl=59 time=26.0 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=34 ttl=59 time=39.5 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=35 ttl=59 time=19.9 ms
^C
--- stackoverflow.com ping statistics ---
50 packets transmitted, 10 received, 80% packet loss, time 49928ms
rtt min/avg/max/mdev = 19.926/302.648/1881.058/580.607 ms, pipe 2
  • google.com 
    $ ping google.com
PING google.com(fra24s12-in-x0e.1e100.net (2a00:1450:4001:831::200e)) 56 data bytes
64 bytes from fra24s12-in-x0e.1e100.net (2a00:1450:4001:831::200e): icmp_seq=1 ttl=118 time=30.0 ms
64 bytes from fra24s12-in-x0e.1e100.net (2a00:1450:4001:831::200e): icmp_seq=2 ttl=118 time=37.2 ms
64 bytes from fra24s12-in-x0e.1e100.net (2a00:1450:4001:831::200e): icmp_seq=3 ttl=118 time=23.7 ms
64 bytes from fra24s12-in-x0e.1e100.net (2a00:1450:4001:831::200e): icmp_seq=4 ttl=118 time=30.4 ms
64 bytes from fra24s12-in-x0e.1e100.net (2a00:1450:4001:831::200e): icmp_seq=5 ttl=118 time=26.4 ms
64 bytes from fra24s12-in-x0e.1e100.net (2a00:1450:4001:831::200e): icmp_seq=6 ttl=118 time=23.8 ms
64 bytes from fra24s12-in-x0e.1e100.net (2a00:1450:4001:831::200e): icmp_seq=7 ttl=118 time=46.0 ms
64 bytes from fra24s12-in-x0e.1e100.net (2a00:1450:4001:831::200e): icmp_seq=8 ttl=118 time=16.1 ms
64 bytes from fra24s12-in-x0e.1e100.net (2a00:1450:4001:831::200e): icmp_seq=9 ttl=118 time=45.3 ms
64 bytes from fra24s12-in-x0e.1e100.net (2a00:1450:4001:831::200e): icmp_seq=10 ttl=118 time=18.0 ms
64 bytes from fra24s12-in-x0e.1e100.net (2a00:1450:4001:831::200e): icmp_seq=11 ttl=118 time=22.3 ms
64 bytes from fra24s12-in-x0e.1e100.net (2a00:1450:4001:831::200e): icmp_seq=12 ttl=118 time=28.0 ms
64 bytes from fra24s12-in-x0e.1e100.net (2a00:1450:4001:831::200e): icmp_seq=13 ttl=118 time=20.7 ms
64 bytes from fra24s12-in-x0e.1e100.net (2a00:1450:4001:831::200e): icmp_seq=14 ttl=118 time=17.3 ms
^C
--- google.com ping statistics ---
14 packets transmitted, 14 received, 0% packet loss, time 13019ms
rtt min/avg/max/mdev = 16.143/27.570/46.096/9.255 ms

tracepath

  • stackoverflow.com 
    $ tracepath stackoverflow.com
1?: [LOCALHOST]                      pmtu 1500
1:  no reply
  • google.com 
    $ tracepath google.com
1?: [LOCALHOST]                        0.034ms pmtu 1500
1:  2a02:908:1866:6ce0:925c:44ff:feae:f4e2                6.422ms 
1:  2a02:908:1866:6ce0:925c:44ff:feae:f4e2                5.390ms 
2:  2a02:908:1800:6::1                                   25.163ms 
3:  de-fra04a-ra1-ae10-1320.fra.unity-media.net          22.841ms 
4:  7113a-mx960-02.dar.unity-media.net                   23.385ms asymm  5 
5:  de-fra04d-rc1-lo0-0.v6.aorta.net                     15.392ms 
6:  no reply

有趣的是，调制解调器的管理员能够执行ping“跟踪路由”，这两项操作都可以正常工作（ping 很短，跟踪通过），就好像根本没有问题一样。

iwconfig

wlp58s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.52  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 2a02:908:1866:6ce0:a0a4:8f72:2826:d298  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::5230:74d:357d:7adc  prefixlen 64  scopeid 0x20<link>
        inet6 2a02:908:1866:6ce0:d570:b754:6e12:8475  prefixlen 64  scopeid 0x0<global>
        ether 9c:b6:d0:dc:58:19  txqueuelen 1000  (Ethernet)
        RX packets 3276896  bytes 2709012463 (2.7 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1563631  bytes 613623237 (613.6 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

DNS

$ systemd-resolve --status
...
Link 2 (wlp58s0)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 192.168.0.1
                      2a02:908:2:a::1
                      2a02:908:2:b::1
          DNS Domain: ~.
                      home

问题

还有什么我可以检查或更改的吗，以帮助解决问题？

更新

现在看起来更像是 ipv6 与 ipv4 的问题

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=10 ttl=118 time=117 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=118 time=58.7 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=118 time=19.7 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=118 time=17.3 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=118 time=16.1 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=118 time=27.5 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=118 time=31.0 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=118 time=22.2 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=118 time=14.1 ms
64 bytes from 8.8.8.8: icmp_seq=73 ttl=118 time=1870 ms
64 bytes from 8.8.8.8: icmp_seq=74 ttl=118 time=847 ms
64 bytes from 8.8.8.8: icmp_seq=75 ttl=118 time=58.9 ms
64 bytes from 8.8.8.8: icmp_seq=76 ttl=118 time=14.5 ms
64 bytes from 8.8.8.8: icmp_seq=77 ttl=118 time=38.9 ms
64 bytes from 8.8.8.8: icmp_seq=78 ttl=118 time=45.6 ms
64 bytes from 8.8.8.8: icmp_seq=79 ttl=118 time=30.4 ms
^C
--- 8.8.8.8 ping statistics ---
79 packets transmitted, 16 received, 79% packet loss, time 79539ms
rtt min/avg/max/mdev = 14.114/201.907/1870.953/473.976 ms, pipe 2

与ping google.com上述相比，它运行起来非常顺畅。如果我在连接设置中禁用 ipv4，有问题的网站https://stackoverflow.com和https://github.com完全停止工作，而https://google.com和https://gitlab.com继续工作，没有问题。

答案1

由于某种原因，我的机器和路由器之间的 IPv4 流量无法顺利传输。

我设法通过使用公共 DNS64 将 ipv4 流量路由到 ipv6 来解决了这个问题。

这个答案帮助过我：

  • 点击WiFi图标。
  • 点击Edit Connections...
  • 从列表中选择您的 SSID。
  • 点击Edit...
  • 选择IPv4 Settings标签
  • 更改Method为Automatic​Disabled
  • 选择IPv6 Settings标签
  • 将方法从 更改Automatic为Automatic, addresses only
  • 在字段中填写DNS servers2-3 个 DNS64 地址

我用了特雷克斯对于 DNS64，在撰写本文时

nameserver 2001:67c:2b0::4
nameserver 2001:67c:2b0::6

相关内容