WSL2使用clash for windows代理

wsl_clash_proxy.sh

# WSL通过Win访问网络，所以WSL的网关指向的是Windows，DNS服务器指向的也是Windows，设置WSL的proxy为win的代理ip+端口即可
# WSL中的DNS server在/etc/resolv.conf中查看，该文件是由/etc/wsl.conf自动生成的。
# 如果关闭了wsl.conf中自动生成resolve.conf并自行修改了resolve.conf，DNS nameserver并不是本机win ip
# 需要开启wsl.conf的自动生成，再运行以下命令
# https://zhuanlan.zhihu.com/p/153124468

# 添加到环境变量设置中，例如~/.zshrc
export hostip=$(cat /etc/resolv.conf |grep -oP '(?<=nameserver\ ).*')
export https_proxy="http://${hostip}:7890"
export http_proxy="http://${hostip}:7890"

找到原因了，防火墙要允许通过clash

好像有点问题，有些网站访问不了

找到原因了，防火墙要允许通过clash

请问是windows的防火墙还是linux的防火墙？如何设置呢？谢谢~

找到原因了，防火墙要允许通过clash

请问是windows的防火墙还是linux的防火墙？如何设置呢？谢谢~

不知道为什么会给我发邮件。我猜层主说的是让 Clash 经过 Windows Defender 的防火墙，这样才有流量进出。

找到原因了，防火墙要允许通过clash

请问是windows的防火墙还是linux的防火墙？如何设置呢？谢谢~

不知道为什么会给我发邮件。我猜层主说的是让 Clash 经过 Windows Defender 的防火墙，这样才有流量进出。

防火墙也按照搜索到的经验设置过了（添加了wsl的允许规则，clash也都设置为允许了），还是不行，很奇怪，能ping通，但无法代理。

找到原因了，防火墙要允许通过clash

请问是windows的防火墙还是linux的防火墙？如何设置呢？谢谢~

不知道为什么会给我发邮件。我猜层主说的是让 Clash 经过 Windows Defender 的防火墙，这样才有流量进出。

防火墙也按照搜索到的经验设置过了（添加了wsl的允许规则，clash也都设置为允许了），还是不行，很奇怪，能ping通，但无法代理。

Ping 走的是單獨的協議，光看 ping 沒有意義。我自己就是透過上面的 bash 脚本實現穿透虛機 proxy 的。你注意查看 Clash 中是否開啓了允許 LAN 鏈接。或者觀察一下流量記錄/日志，看看有沒有從 WSL 裡出流量。

找到原因了，防火墙要允许通过clash

请问是windows的防火墙还是linux的防火墙？如何设置呢？谢谢~

不知道为什么会给我发邮件。我猜层主说的是让 Clash 经过 Windows Defender 的防火墙，这样才有流量进出。

防火墙也按照搜索到的经验设置过了（添加了wsl的允许规则，clash也都设置为允许了），还是不行，很奇怪，能ping通，但无法代理。

Ping 走的是單獨的協議，光看 ping 沒有意義。我自己就是透過上面的 bash 脚本實現穿透虛機 proxy 的。你注意查看 Clash 中是否開啓了允許 LAN 鏈接。或者觀察一下流量記錄/日志，看看有沒有從 WSL 裡出流量。

是的，clash上面已经设置过允许LAN连接了（虽然还是不行，我再观察一下流量好了

感谢！终于解决了，粘贴代码后重启windows系统， clash 开启 Allow Lan ，ok了！

找到原因了，防火墙要允许通过clash

请问是windows的防火墙还是linux的防火墙？如何设置呢？谢谢~

不知道为什么会给我发邮件。我猜层主说的是让 Clash 经过 Windows Defender 的防火墙，这样才有流量进出。

防火墙也按照搜索到的经验设置过了（添加了wsl的允许规则，clash也都设置为允许了），还是不行，很奇怪，能ping通，但无法代理。

Ping 走的是單獨的協議，光看 ping 沒有意義。我自己就是透過上面的 bash 脚本實現穿透虛機 proxy 的。你注意查看 Clash 中是否開啓了允許 LAN 鏈接。或者觀察一下流量記錄/日志，看看有沒有從 WSL 裡出流量。

是的，clash上面已经设置过允许LAN连接了（虽然还是不行，我再观察一下流量好了

发现是因为从WSL访问不了PC的7890端口，而且我已经验证PC的Clash 7890端口权限放开（局域网手机设置代理为PC的7890且可访问外网）。PC的Clash本身是没问题的，问题在WSL到PC的端口（从WSL telnet这个端口也是不通）。不知道该设置哪里。

我说一下我的心得啊：
1.首先确定你的clash打开了LAN开关
2.确定把防火墙关了（先全部关闭，然后能链接了以后再打开添加规则）
3.使用Nmap -p7890 hostip 测试看看，station是否是open
4.然后执行这三行代码
export hostip=$(cat /etc/resolv.conf |grep -oP '(?<=nameserver\ ).*')
export https_proxy="http://${hostip}:7890"
export http_proxy="http://${hostip}:7890"
5.测试是否成功

然而，在我的wsl上配置这三行代码并不生效。

我是直接将配置改成电脑的本地ip，而不是nameserver（运行cat /etc/resolv.conf |grep -oP '(?<=nameserver\ ).*'的值）

比如：
export https_proxy="http://192.168.1.6:7890" export http_proxy="http://192.168.1.6:7890"

另外，我开启了7890的windows防火墙端口。

可以正常访问外网，但是ping无法成功。

想知道export后面的变量是否区分大小写，这么配置变量的出处在哪里?

感谢

然而，在我的wsl上配置这三行代码并不生效。

我是直接将配置改成电脑的本地ip，而不是nameserver（运行cat /etc/resolv.conf |grep -oP '(?<=nameserver\ ).*'的值）

比如： export https_proxy="http://192.168.1.6:7890" export http_proxy="http://192.168.1.6:7890"

另外，我开启了7890的windows防火墙端口。

可以正常访问外网，但是ping无法成功。

---

根据我的经验，假设运行clash的ip为192.168.1.1，那么只需要两步操作：

1. 打开clash的Allow LAN
2. 运行代码（可以设置开机自动运行）

export http_proxy=http://192.168.1.1:7890
export https_proxy=http://192.168.1.1:7890

不需要打开防火墙，因为wsl和clash运行在同一台电脑。
如果其他设备（比如手机）需要通过电脑的clash进行代理，那么可以放开防火墙的7890端口

@Yuansheng-Liang

根据我的经验，假设运行clash的ip为192.168.1.1，那么只需要两步操作：

设置代理确实可以成功，我在Android studio 中设置http代理，gradle 就可以正常下载

如果有人按照这个操作失败了，可以试试这里面的

microsoft/WSL#10753

如果有人按照这个操作失败了，可以试试这里面的

microsoft/WSL#10753

这对我有效，我使用如下配置(%USERPROFILE%\.wslconfig)：

[wsl2]
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

[experimental]
# requires dnsTunneling but are also OPTIONAL
bestEffortDnsParsing=true
useWindowsDnsCache=true

如果有人按照这个操作失败了，可以试试这里面的
microsoft/WSL#10753

这对我有效，我使用如下配置(%USERPROFILE%\.wslconfig)：

[wsl2]
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

[experimental]
# requires dnsTunneling but are also OPTIONAL
bestEffortDnsParsing=true
useWindowsDnsCache=true

但是这样设置了之后，网络变得很慢，连 sudo apt update 都下半天，不知道你有没有遇到过这个情况？

如果有人按照这个操作失败了，可以试试这里面的
microsoft/WSL#10753

这对我有效，我使用如下配置(%USERPROFILE%\.wslconfig)：

[wsl2]
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

[experimental]
# requires dnsTunneling but are also OPTIONAL
bestEffortDnsParsing=true
useWindowsDnsCache=true

但是这样设置了之后，网络变得很慢，连 sudo apt update 都下半天，不知道你有没有遇到过这个情况？

没有哦

我的问题比较奇怪，不知道有没有人有遇到过，直接用wsl2和clash的话，是可以访问外网的，但是使用apt-get update的时候，会一直卡在0%的进度，但是能ping通源的域名，单独关闭设置里的代理也不行，必须要把clash也关掉才能update成功。

我的问题比较奇怪，不知道有没有人有遇到过，直接用wsl2和clash的话，是可以访问外网的，但是使用apt-get update的时候，会一直卡在0%的进度，但是能ping通源的域名，单独关闭设置里的代理也不行，必须要把clash也关掉才能update成功。

If you are using the http_proxy variable, you need to check whether the http_proxy variable continues to be used after running sudo. Generally, sudo will clear the environment variables of the common user by default. Previously, I encountered this issue where sudo curl ip.gs could not use the proxy due to this reason.
I eventually solved the issue by modifying the /etc/sudoers file using sudo visudo and adding Defaults env_keep += "http_proxy https_proxy ftp_proxy no_proxy", which allowed sudo to use the proxy correctly.

cat /etc/resolv.conf | grep nameserve查看内容 ，是否与Ethernet adapter vEthernet (WSL)地址一样 如果是其他，可能是resolv.conf中文件内容不一致，导致没办法正常提取到地址

以下为我的解决方案
powershell.exe -Command "(ipconfig)" # 此命令的结果和在windows中 ipconfig结果是一样的
可以看到这里是有Ethernet adapter vEthernet (WSL)地址的,然后抓取地址
powershell.exe -Command "(ipconfig)" | grep -a IPv4 | grep -a 17 | awk '{print $16}' # 我这里是16，可能需要修改

shell脚本中:
hostip=$(powershell.exe -Command "(ipconfig)" | grep -a IPv4 | grep -a 172 | awk '{print $16}')
hostip=$(echo -e "$hostip" | tr -d '\r') #将从powershell获得的CRLF 类型的转换为LF

其他解决方案:
和上面一样修改%USERPROFILE%.wslconfig配置
加入如下内容

[wsl2]
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

[experimental]
# requires dnsTunneling but are also OPTIONAL
bestEffortDnsParsing=true
useWindowsDnsCache=true

在较新版本中，在mirror模式下，WSL2 已经支持和宿主机共享 IP
可以直接使用127.0.0.1:port的地址
微软官方详细

我的问题比较奇怪，不知道有没有人有遇到过，直接用wsl2和clash的话，是可以访问外网的，但是使用apt-get update的时候，会一直卡在0%的进度，但是能ping通源的域名，单独关闭设置里的代理也不行，必须要把clash也关掉才能update成功。

If you are using the http_proxy variable, you need to check whether the http_proxy variable continues to be used after running sudo. Generally, sudo will clear the environment variables of the common user by default. Previously, I encountered this issue where sudo curl ip.gs could not use the proxy due to this reason. I eventually solved the issue by modifying the /etc/sudoers file using sudo visudo and adding Defaults env_keep += "http_proxy https_proxy ftp_proxy no_proxy", which allowed sudo to use the proxy correctly.

worked for me, thanks you