根据你的机器配置和问题描述，这个故障大概率是NetworkManager的强制门户（Captive Portal）检测逻辑或DNS解析异常导致的——毕竟Windows系统能正常连接，说明WiFi本身的认证流程是没问题的。结合你已经尝试过的方法，给你几个针对性的解决方案：

方案一：禁用NetworkManager的强制门户检测 #

Ubuntu 17.10的NetworkManager默认会自动检测WiFi的认证门户，一旦检测到需要认证就会触发重定向，但如果重定向目标域名无法解析，就会卡住连接流程。你可以直接关闭这个检测：

1. 打开NetworkManager的主配置文件：

   sudo nano /etc/NetworkManager/NetworkManager.conf
   

2. 在[main]段落中添加或修改如下配置：

   captive-portal-mode=none
   

3. 保存文件后重启NetworkManager服务：

   sudo systemctl restart NetworkManager
   

4. 重新扫描并连接RED_STB WiFi，输入密码后观察是否能正常获取网络。

方案二：锁定自定义DNS，避免resolvconf自动覆盖 #

你之前尝试过手动添加DNS，但可能被resolvconf的自动配置覆盖了。试试这个方法强制保留自定义DNS：

1. 打开resolvconf的预配置文件：

   sudo nano /etc/resolvconf/resolv.conf.d/head
   

2. 在文件顶部添加可靠的公共DNS服务器（比如谷歌DNS）：

   nameserver 8.8.8.8
   nameserver 8.8.4.4
   

3. 保存后更新resolvconf生效：

   sudo resolvconf -u
   

4. 再次连接RED_STB WiFi，此时系统会优先使用你指定的DNS，应该能正常解析重定向的域名。

方案三：手动添加hosts映射跳过DNS解析 #

如果是目标域名wifiinstant.netsecure.pe本身无法被公共DNS解析，你可以通过Windows获取该域名的真实IP，然后在Ubuntu的hosts文件中直接映射：

1. 在Windows连接RED_STB WiFi后，打开命令提示符执行：

   ping wifiinstant.netsecure.pe
   

   记录返回的IP地址（比如假设是192.168.0.10，实际以你获取的结果为准）。
2. 在Ubuntu中打开hosts文件：

   sudo nano /etc/hosts
   

3. 在文件末尾添加一行映射：

   192.168.0.10    wifiinstant.netsecure.pe
   

4. 保存文件后重新连接WiFi，系统会直接访问指定IP完成认证流程。

补充：重置WiFi连接配置 #

如果以上方案都无效，你可以尝试重置该WiFi的连接配置，从头开始建立连接：

sudo rm -rf /etc/NetworkManager/system-connections/RED_STB
sudo systemctl restart NetworkManager

然后重新扫描RED_STB WiFi，输入密码后观察连接状态。

内容的提问来源于stack exchange，提问作者Brandon Bertelsen