Android 打不开 VPN 文件共享里的文件

手机已经连上 VPN，文件服务器也能响应 ping，可文件应用仍然提示无法连接，或者虽然连上了，设备上却没有任何编辑器能打开它列出的文件。这是两种不同的故障，而且都不意味着隧道坏了。VPN 只提供一条进入私有网络的路由；浏览共享、向共享认证、把文档交给另一个应用，是彼此独立的步骤，失败的环节也各不相同。下面是我检查的顺序，以及我停止猜测的那个点。

先检查服务，再怪隧道

能回 ping 或能打开 NAS 的网页，只能证明路由通，别的什么都证明不了。你真正需要的服务，445 上的 SMB、22 上的 SFTP 或 443 上的 WebDAV，可能被停用、被防火墙拦住，或者绑定在 VPN 子网到不了的接口上。用手机上能显示真实错误的客户端去测那个具体端口，而不是看通用的网络提示。如果端口被过滤，就修服务或防火墙规则，因为再好的文件应用也绕不过一个关着的端口。

还要看服务器收到的源地址是什么。把共享所在子网排除在外的拆分隧道，或让文件应用留在 VPN 之外的单应用隧道，都会造成一模一样的有连接、不可达的症状。

不要因为一个客户端认证不了，就图省事打开来宾访问或 SMB1。这类改动会扩大服务器对网络上每台设备的接受范围，而且如果底层问题是路由或名称解析，它什么也修不好。如果共享需要指定账户，就用那个账户，包括服务器要求的域或工作组前缀。

用自己会说协议的文件应用

Android 没有内置的网络共享浏览器，所以客户端应用是实打实的依赖，不是细节。要选实现了你实际所用协议、而且仍在维护的那一个，因为为早已不用的 Android 版本构建的客户端，出问题时的表现很像网络故障。当自动发现跨不过子网时，直接手动输入主机名，不要等应用自己找到。

用 IP 试一次服务器，把 DNS 和路由分开。如果 IP 能通、名字不通，说明手机走的是一个看不到你私有区的 DNS 服务器。

搞清楚接收方拿到的是 URI，而不是路径

如果你的文件应用实现了 DocumentsProvider，Android 的存储访问框架就能在系统选择器里显示它的内容，你选中的应用拿到的是一个 content:// URI 加一份权限授予。那份授予不是文件系统路径，所以坚持要原始路径名的编辑器即使选择器列出了文档也打不开。Android 文档访问指南描述了这个模型：提供方拥有字节，使用方通过系统读取。接受 URI 的应用能工作，对路径调用 open() 的应用不行。这是共享在文件应用里能用、在别处全都失败的最常见原因。

另一种做法是有意复制：把文件拉到编辑器自己的存储里，改完再传回去。这是完全可行的流程，但会产生第二份副本和冲突问题，所以在火车上开始编辑之前，先想清楚哪边说了算。

按应用分配 VPN 的策略在这里也值得看一眼。真正执行网络读取的包往往是提供方应用，而不是编辑器，所以要把正确的包放进隧道，别只看你点开的那个图标。

分别测试读、写和权限能否存活

能列出目录只证明读路径通。用一个无害的测试文件走完整流程：列出、打开、编辑、保存，然后从桌面客户端重新打开同一个文件。

注意重启后权限还在不在。存储授权是临时的，除非应用把它持久化；有些编辑器每次启动都重新申请，另一些则悄悄失败，给你看一份过期副本。如果保存看起来成功了，就到服务器一侧确认：看修改时间，或从另一台机器重新打开。也要测保存中途断开，因为上传时 VPN 掉线，正是客户端最容易留下半个文件或一份永远不会同步的本地改动的时候。

把 Android 的 URI 权限和服务器上的授权分开看。能打开文档，并不说明它背后的 SMB 账户有权限。

把挂载共享留给确实需要它的场景

root 级别的 CIFS 挂载和内核文件系统模块依然存在，它们给每个应用一个本地目录的错觉。它们还需要 root，内核一变就容易坏，而且把网络故障藏进文件系统层，诊断起来更难。在手机上编辑文档，提供方或复制流程已经覆盖了人们真正需要的大部分情况。

在把工作流建在上面之前，先确认挂载能不能扛住网络切换。从桌上笔记本挂载的共享，和反复在 Wi-Fi 与蜂窝之间跳的手机，行为并不一样；一个失效的挂载还可能让应用卡住，而不是干脆报错。

如果还是卡着，就按清单逐项走，在第一个失败的环节停下：端口可达、协议客户端已安装、共享已认证、选择器能看到文件、编辑器接受 URI、保存落到服务器上。那一步会告诉你该修哪个部件，而它很少是隧道。