先确认 v2rayN 本地监听端口，再检查 macOS 当前网络服务的代理设置；浏览器单独排除扩展干扰，终端用 curl 与环境变量分别验证。适合客户端已连接、但不同应用表现不一致时按层定位。
先区分：客户端、系统代理与应用程序
v2rayN 显示节点已选中，不等于每个程序都会使用该节点。应用需要把请求交给本机代理端口，v2rayN 才能处理后续连接。macOS 的系统代理主要为遵循系统网络设置的应用提供地址；终端命令行工具可能另读环境变量，也可能需要显式指定代理。
开始排查前，在 v2rayN 查看本地 HTTP 与 SOCKS 监听地址，并确认内核处于运行状态。下方数字只是一组演示填写值，不代表你的安装一定使用这些端口；后续所有命令与系统设置，都应替换成客户端当前显示的实际值。
先判断故障边界
浏览器与终端同时失败，先查内核和本地端口；只有浏览器失败，先查系统代理与扩展；只有终端失败，先查命令本身是否读取了代理设置。不要在尚未确认监听端口时反复更换节点。
检查 macOS 当前网络服务的代理设置
先在 v2rayN 的系统代理菜单确认已选择「自动配置系统代理」，再到 macOS 查看设置是否落在正在使用的网络服务上。系统界面的位置会随 macOS 版本及 Wi-Fi、以太网连接方式变化；较新的界面通常从「系统设置」→「网络」→当前网络服务→「详细信息」→「代理」进入。
确认内核运行
查看 v2rayN 主界面状态与日志。若内核尚未启动，系统即使填写了代理地址，也无法连接到本地端口。
读取监听端口
在 v2rayN 的「设置」→「参数设置」中核对本地代理端口，并以当前界面及日志显示的监听结果为准。区分 HTTP 端口与 SOCKS 端口，不要交叉填写。
选择系统代理
在 v2rayN 的系统代理菜单选择「自动配置系统代理」，随后打开 macOS「系统设置」→「网络」→当前网络服务→「详细信息」→「代理」核对地址与端口。
核对网络服务
正在使用以太网时，不要只检查 Wi-Fi 的代理选项。若切换过网络连接，重新查看当前服务；同时留意是否启用了旧的自动代理配置或其他手动代理。
手动配置时，HTTP 代理和安全网页代理应使用实际的 HTTP 监听端口；SOCKS 代理应使用实际的 SOCKS 监听端口。示例地址 127.0.0.1 仅指这台 Mac 自身，不能把远端节点地址填入系统代理栏。若客户端生成的是自动代理配置，应核对其状态，不要把配置地址误当成普通 HTTP 代理服务器。
还可以在终端运行下面的只读命令，观察系统当前暴露的代理配置。输出中若出现旧地址或旧端口，先回到当前网络服务的设置页修正，再重新启动需要测试的应用。
scutil --proxy
networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsocksfirewallproxy "Wi-Fi"浏览器无效：排除独立代理与扩展冲突
浏览器能够打开网页，只能说明当前访问路径可用，不能单凭这一点证明它正在使用 v2rayN。相反，浏览器打不开而其他应用正常，也不一定是节点故障。先用同一个明确的网址重复测试，并记录是所有网站都失败，还是仅个别网站失败。
- 检查浏览器自己的代理入口：若浏览器提供代理设置入口，确认它指向 macOS 系统代理，而不是先前留下的手动服务器地址。
- 暂时停用会改写代理的扩展：尤其注意代理切换、请求转发类扩展。停用后新开窗口测试，避免把扩展规则和系统设置同时作为变量。
- 核对当前网络与登录状态：网络切换后重新检查对应服务的代理项。需要门户页面登录的公共网络，应先完成该网络自身的连接步骤。
- 比较普通窗口与新会话：若只有原窗口异常，再检查站点缓存、浏览器配置或扩展；不要直接改动 v2rayN 节点参数。
若浏览器提示代理服务器拒绝连接，优先核对系统代理中的本机地址、端口与内核监听状态。若页面已经建立连接，却只在某个网站出现证书错误或访问失败，应把它作为该网站或浏览器的独立问题排查，不要通过关闭证书验证来掩盖错误。
用独立请求交叉验证
浏览器结果不明确时，用下一节的 curl -x 显式指定同一个本地端口。显式请求成功、浏览器失败，排查重点就可以收窄到浏览器设置、扩展与 macOS 当前网络服务。
终端无效：分别测试显式代理与环境变量
终端不是一个统一的网络客户端：curl、包管理工具与其他命令各有代理读取方式。先绕开系统设置，直接让 curl 连接 v2rayN 的示例 HTTP 端口。若你的 HTTP 端口不是 10809，必须先替换命令中的数字。
curl -v -x http://127.0.0.1:10809 -I https://example.com关注输出里连接的代理地址、HTTP CONNECT 阶段以及最终的响应或报错。连接被拒绝通常说明这个端口没有程序监听，或端口填错；请求已到达代理却迟迟没有响应，则继续看 v2rayN 日志、节点配置与目标站点。-I 只请求响应头，个别站点对这类请求处理不同，可改用不带 -I 的命令复测。
显式指定
先运行上面的
curl -x命令。它用于确认本机 HTTP 端口能否处理请求，不依赖 shell 是否设置了代理变量。查看变量
运行
env | grep -i proxy，检查是否残留旧地址、错误端口，或让目标域名绕过代理的NO_PROXY配置。当前会话设置
显式请求成功后，再按下方示例为当前终端会话设置变量，运行不带
-x的curl对比结果。逐个验证工具
其他命令仍无效时，查该工具自己的代理选项或配置文件。不要把
curl的行为直接推断成所有命令行程序的行为。
env | grep -i proxy
export http_proxy=http://127.0.0.1:10809
export https_proxy=http://127.0.0.1:10809
curl -v -I https://example.comhttps_proxy 的值写成 http:// 并不表示目标网站改用明文 HTTP；这里标识的是连接本地 HTTP 代理的方式，HTTPS 目标通常通过 CONNECT 建立通道。如果只提供 SOCKS 端口，可针对支持 SOCKS 的工具使用相应选项，例如 curl --socks5-hostname 127.0.0.1:10808 -I https://example.com；其中 --socks5-hostname 让域名交由 SOCKS 代理处理。
按报错定位：端口、地址与证书
报错原文能帮助确定请求停在哪一层。以下示例中的地址和端口仍沿用前文的演示值；不同系统或工具的措辞可能略有差异，应结合实际命令输出与 v2rayN 日志判断。
报错:curl: (7) Failed to connect to 127.0.0.1 port 10809: Connection refused
原因与解法:请求尚未进入代理处理阶段。核对 v2rayN 内核是否运行、HTTP 实际监听端口是否为 10809，以及命令中是否误用了 SOCKS 端口。
报错:curl: (5) Could not resolve proxy: proxy.invalid
原因与解法:命令或环境变量指向了无法解析的代理主机名。检查 env | grep -i proxy 与工具自身设置，把旧代理地址改为实际本机监听地址。
报错:curl: (60) SSL certificate problem: unable to get local issuer certificate
原因与解法:连接已进入证书验证阶段，不能仅凭此报错认定本地代理端口故障。检查系统时间、目标站点证书及相关网络环境，保留证书验证后再复测。
如果 curl -x 成功，而不带 -x 的同一命令失败，重点检查环境变量、NO_PROXY 和命令自身的代理配置。如果两种调用都失败，先查看 v2rayN 日志是否记录到这次请求；日志没有记录时，优先回到监听地址和端口。
切换网络或修改系统代理后，重新发起请求再观察日志。不要把之前的连接记录当作本次测试结果；同时避免一次改动节点、浏览器扩展和 shell 配置，否则即使恢复访问，也难以知道是哪一步起效。
恢复设置并做一次分层复测
排查结束后，保留一种清楚的配置路径：浏览器按需使用 macOS 系统代理，终端工具按需使用自己的代理参数或环境变量。若只是临时测试，不必把演示端口永久写入所有终端会话。
- 先测客户端：确认 v2rayN 内核运行，记下当前 HTTP、SOCKS 监听端口，并查看新请求是否出现在日志中。
- 再测系统与浏览器：核对当前网络服务的代理项，停用冲突扩展后新开窗口访问同一测试地址。
- 最后测终端：先执行显式指定端口的
curl -x，成功后再测试环境变量及实际要使用的命令。 - 清理临时变量：不再需要本次 shell 测试值时，运行
unset http_proxy https_proxy；若还设置过其他代理变量，也按实际名称分别清理。
这样的顺序把「本地端口是否可用」「系统设置是否被应用读取」「命令是否自行配置代理」分开验证。若端口和显式请求均正常，就不必从头重配节点；若显式请求仍失败，再回到客户端日志与节点配置继续检查。