v2ray does not work on raspberry pi but works fine on x64 laptop with same config #3378

VarmRay · 2025-04-10T19:27:57Z

VarmRay
Apr 10, 2025

I have two machines, one laptop with a debian 12 x64 linux and a raspberry pi (rasbian). Both should connect to a server via v2ray. I downloaded and ran v2ray v5.28.0 successfully on the server and the laptop. The connection works fine and applications on the laptop have the server as proxy.

When I try the same thing on the raspberry pi, all applications trying to connect report a kindof of empty response error. E.g. curl:

$ curl --socks5-hostname localhost:1080 startpage.com
curl: (52) Empty reply from server

Firefox shows a Secure Connection Failed page with PR_END_OF_FILE_ERROR error code. There are many things that are same between the laptop and rasbperry pi:

they are in the same network, connected via DHCP
they use the same configuration except the "id" field. I even tried using the exact same configuration, though not at the same time.
Same systemd configuration between the two
No firewall enabled on both the laptop as well as the raspberry pi (sudo nft list ruleset produces no output)

I also tried switching to v2ray v5.29.3 on the raspberry pi, but it didn't help. The server does not show any logs from the raspberry pi. Only when I use the v2ray client on the laptop, some v2ray logs show up on the server. The setup on the server is a v2ray behind nginx for obfuscation, but since it works on the laptop in the end, I guess it shouldn't matter?

Does anyone have an idea what has gone wrong or why v2ray doesn't work on the raspberry pi? Thanks!

tomandjerry27 · 2025-04-28T19:09:32Z

tomandjerry27
Apr 28, 2025

你是否是无线网络?你是否只为server使用ipv6?
我没有用过树莓派，但我有一个香蕉派。香蕉派是树莓派的众多模仿者之一。
我为了在香蕉派上使用dockor，我需要让树莓派先运行v2ray，因为docker仓库在中国被封锁。
所以说我尝试做过和你一样的事情，结果是无法使用v2ray。我找到了原因，但我无法解决。可能我需要为香蕉派编译一个Linux发行版系统才能解决，但我没去尝试，所以只能给你参考一下。
由于ipv4资源的短缺（这个不多余解释，不然太长了），我选择在proxy server上使用ipv6。也就是说我的香蕉派连接到proxy server上的IPv6。
而香蕉派看起来不支持IPv6?我不知道该如何描述这件事。因为香蕉派的Linux发行版上是支持ipv4/6双栈的，而且默认是打开状态。
我发现无法使用ipv6后，我输入了ip show（应该是这个命令吧，他是ifconfig的新继任者），在结果当中，ipv6地址赫然在列。但是wpa那种命令是显示未获取到ipv6地址。事实上也是如此，所有的网络包只能使用ipv4地址。所以事情看起来很奇怪，香蕉派的无线网络处在一个我看不懂的状态。
大家常说重启解决90%问题，重装解决99%问题。所以我去香蕉派资源中心下载了几个可以用的Linux发行版镜像刷进香蕉派。可尝试过后都是一样的，奇怪的情况依然存在。
我遇到的这个情况和v2ray无关，因为问题出在ipv6上。但很多镜像都无法使用IPv6，这或许意味着这也不是操作系统的问题，所以我没有去尝试自己编译操作系统。
我的遭遇分享给你，你可以参考。

1 reply

tomandjerry27 Apr 28, 2025

抱歉，我每次在这种香蕉派和树莓派一起出现的场合，总是会弄混他们。也许在中文里他们看起来比较接近。我只有一个香蕉派，我使用的是香蕉派，希望你能看明白，别被我带偏了。

VarmRay · 2025-05-11T14:31:15Z

VarmRay
May 11, 2025
Author

@tomandjerry27 I don't use WiFi and my proxy server has an IPv4 address. Interestingly, I'm currently not located in a restricted network.

I compared the two machines (X86-64 and raspberry pi) again:
** On X86-64 machine:**

$ curl --socks5-hostname localhost:1080 startpage.com
curl: (52) Empty reply from server
$ systemctl status v2ray
● v2ray.service - V2Ray Service
     Loaded: loaded (/lib/systemd/system/v2ray.service; disabled; preset: enabled)
     Active: active (running) since Sun 2025-05-11 16:08:50 <My-timezone>; 17s ago
       Docs: https://www.v2fly.org/
   Main PID: 3035 (v2ray)
      Tasks: 8 (limit: 3913)
        CPU: 1.621s
     CGroup: /system.slice/v2ray.service
             └─3035 /usr/local/bin/v2ray run -config /usr/local/etc/v2ray/config.json

May 11 16:08:50 raspberry-pi systemd[1]: Started v2ray.service - V2Ray Service.
May 11 16:08:50 raspberry-pi v2ray[3035]: V2Ray 5.29.3 (V2Fly, a community-driven edition of V2Ray.) Custom (go1.23.7 linux/arm64)
May 11 16:08:50 raspberry-pi v2ray[3035]: A unified platform for anti-censorship.
May 11 16:08:51 raspberry-pi v2ray[3035]: 2025/05/11 16:08:51 [Warning] V2Ray 5.29.3 started
May 11 16:09:02 raspberry-pi v2ray[3035]: 2025/05/11 16:09:02 [Warning] [3973260010] app/dispatcher: default route for tcp:startpage.com:80

On X86-64 machine:

$ curl --socks5-hostname localhost:1080 startpage.com
<html>
<head><title>302 Found</title></head>
<body>
<center><h1>302 Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
$ journalctl -u v2ray
...
May 11 16:11:34 x86-64-machine systemd[1]: Started v2ray.service - V2Ray Service.
May 11 16:11:34 x86-64-machine v2ray[39518]: V2Ray 5.28.0 (V2Fly, a community-driven edition of V2Ray.) Custom (go1.23.6 linux/amd64)
May 11 16:11:34 x86-64-machine v2ray[39518]: A unified platform for anti-censorship.
May 11 16:11:34 x86-64-machine v2ray[39518]: 2025/05/11 16:11:34 [Warning] V2Ray 5.28.0 started
May 11 16:11:38 x86-64-machine v2ray[39518]: 2025/05/11 16:11:38 [Warning] [2883346356] app/dispatcher: default route for tcp:startpage.com:80

I checked with a custom firewall log rule and on the Raspberry Pi, nothing can be see, while on the X86-64 machine, there are a bunch of logs of packets going to the proxy server.

1 reply

tomandjerry27 May 12, 2025

我注意到你两台机器上systemctl status v2ray的输出中都有一行相同的信息：app/dispatcher: default route for tcp:startpage.com:80
startpage.com:80毫无疑问就是你之前测试的网站。既然出现这行信息，便代表着无论是在x86-64还是raspberry pi上，v2ray client都成功接受到了inbounds。
所以已知inbounds正常。但，树莓派v2ray clinet的outbounds结果是怎么样的呢？问题是出在v2ray outbounds上吗？也许outbounds也是正常的，问题在树莓派自身的网络配置，比如dns。又或者v2ray outbounds的send port被别的程序占用了？我想目前看来有太多可能性了，能不能尽量缩小排查范围？
你查看了firewall log，可惜里面没有记录到v2ray的流量，那么你可能还是没搞清楚v2ray outbounds的情况。
如果你可以去判断一下树莓派v2ray outbounds是否正常。那么就可以大大缩小怀疑范围。
app/dispatcher: default route for tcp:startpage.com:80这类信息被记录在error.log中。
而access.log中的信息应该足够你判断outbounds是否正常。
你应该知道怎么查看这两个log文件吧。以防万一你不清楚，我还是说一下吧。access.log和access.log的文件位置被记录在v2ray config.json中，就像这样：

"log": {
        "access": "/var/log/v2ray/access.log",
        "error": "/var/log/v2ray/error.log",
        "loglevel": "warning"
    },

如果这里是空的，意味着你的v2ray没在记录log。你把它补上，然后重启v2ray，重新发送网络请求，新log内容就会出现了。
如果你开启日志记录功能使用了很久v2ray，你的log文件可能超级超级长，那么建议使用tail命令

$tail -n 100 /var/log/v2ray/access.log

VarmRay · 2025-05-18T15:03:31Z

VarmRay
May 18, 2025
Author

Thanks for the reply!

I put "loglevel" to "debug". Now I actually seen an error in error.log (I masked the real server name with testserver.example):

2025/05/18 16:45:39 [Debug] app/log: Logger started
2025/05/18 16:45:39 [Debug] app/proxyman/inbound: creating stream worker on 0.0.0.0:1080
2025/05/18 16:45:39 [Info] transport/internet/tcp: listening TCP on 0.0.0.0:1080
2025/05/18 16:45:39 [Info] transport/internet/udp: listening UDP on 0.0.0.0:1080
2025/05/18 16:45:39 [Warning] V2Ray 5.29.3 started
2025/05/18 16:45:42 [Info] [3957476813] proxy/socks: TCP Connect request to tcp:startpage.com:80
2025/05/18 16:45:42 [Warning] [3957476813] app/dispatcher: default route for tcp:startpage.com:80
2025/05/18 16:45:42 [Info] [3957476813] transport/internet/websocket: creating connection to tcp:testserver.example:443
2025/05/18 16:45:43 [Info] [3957476813] proxy/vmess/outbound: tunneling request to tcp:startpage.com:80 via testserver.example:443
2025/05/18 16:45:43 [Info] [3957476813] app/proxyman/outbound: failed to process outbound traffic > proxy/vmess/outbound: connection ends > proxy/vmess/outbound: failed to read header > common/drain: common/drain: unable to drain connection > websocket: close 1000 (normal) > proxy/vmess/encoding: Unable to Read Header Len > websocket: close 1000 (normal)
2025/05/18 16:45:43 [Info] [3957476813] app/proxyman/inbound: connection ends > proxy/socks: connection ends > proxy/socks: failed to transport all TCP response > io: read/write on closed pipe

access.log contains the log I've seen in journalctl before:

2025/05/18 16:45:42 tcp:127.0.0.1:34246 accepted tcp:startpage.com:80

Please not that v2ray still works without issues on another machine in the same private network (behind the same NAT-router).

0 replies

tomandjerry27 · 2025-05-19T15:16:07Z

tomandjerry27
May 19, 2025

From your V2Ray logs, it appears you are using the vmess–WebSocket–TLS–TCP protocol chain. By interpreting those log entries, we can roughly deduce the cause—at least, that’s what an AI would conclude. I myself use the vmess–TLS–TCP chain and don’t fully understand WebSocket’s internal logic, which is why I turned to the AI for help.
I’m also confused by your firewall statements. First you said:
“No firewall enabled on both the laptop as well as the Raspberry Pi (sudo nft list ruleset produces no output),”
and then later:
“I checked with a custom firewall log rule and on the Raspberry Pi, nothing can be seen, while on the x86‑64 machine, there are a bunch of logs of packets going to the proxy server.”
Those two claims contradict each other, so I’m not sure whether you actually had any firewall logging in place.
When I look at the V2Ray logs, I see that the Raspberry Pi’s connection to the proxy server was indeed successfully established. That doesn’t match your report of “nothing” in the custom firewall log, so I’m even more puzzled.
In cases of conflicting information, I can only trust one data source. I believe the V2Ray logs are more reliable, because they’re copied directly from your application and I’ve seen them with my own eyes. Your firewall info is second‑hand—perhaps your custom rule was misconfigured or incomplete.
In any event, the AI has suggested several possible root causes and how to troubleshoot them. Here they are:
**[
From your V2Ray logs, it appears you are using the vmess-websocket-tls-tcp transport chain. Based on the log excerpts, the connection to your proxy server is indeed being established, so the issue likely lies in one of the following areas:

Confirm client/server VMess AEAD configuration is identical
Make sure that on both client and server you have the same id, alterId (or security/cipher settings if using newer AEAD modes), and that VMess AEAD is enabled or disabled consistently on both ends
Synchronize and verify system time
On Linux devices—especially single‑board computers like Raspberry Pi without a real‑time clock battery—unsynced clocks will break TLS and VMess handshakes. Use ntpdate or install/configure chrony to auto‑sync time on boot and periodically
Validate WebSocket settings (path, Host header, TLS SNI)
Ensure the path you configured for WebSocket on the client exactly matches the server’s wsSettings.path, and that the HTTP Host header (in client’s wsSettings.headers) and TLS SNI (streamSettings.tlsSettings.serverName) all match your server’s certificate CN/subjectAltName
Test WebSocket handshake with curl
From the client to the server, run:

curl --http1.1 --silent --insecure \
  https://testserver.example:443/your/ws/path \
  -H "Host: your.domain.com" -H "Connection: Upgrade" -H "Upgrade: websocket"

A successful WebSocket handshake (status 101 Switching Protocols) confirms that the TCP+TLS+WebSocket layers are functioning
]**
Because you have both an x86-64 server and a Raspberry Pi, the chance of clock drift on the Pi is especially high. As I mentioned earlier, unlike a PC with its little CMOS battery, a Pi won’t keep accurate time across power cycles unless an NTP sync runs at startup. Without correct time, the vmess protocol simply won’t work.
I used AI to translate.

0 replies

tomandjerry27 · 2025-05-19T15:22:02Z

tomandjerry27
May 19, 2025

我觉得AI翻译效果很差啊，总是吞掉一些意思，我很无奈。你自己找软件翻译吧。
从你提供的v2ray日志来看，你所使用的协议链应该是vmess-websocket-tls-tcp。通过判读你日志可以大致分析出原因了，起码AI是这么认为的。我自己使用的是vmess-tls-tcp的协议链，我完全不了解websocket的运行逻辑，所以我就去求助AI了。
另外，我对于你的回复感到很困惑。你第一次的时候说"No firewall enabled on both the laptop as well as the raspberry pi (sudo nft list ruleset produces no output)"，后面又说"I checked with a custom firewall log rule and on the Raspberry Pi, nothing can be see, while on the X86-64 machine, there are a bunch of logs of packets going to the proxy server."这就已经让我对于你到底有没有启用firewall感到困惑了。
而当我看到v2ray日志的时候，我能够知道树莓派到proxy server的连接已经成功建立。这和你说的custom firewall log rule为空又不一致，所以我更困惑了。
无论如何，在信息有矛盾的情况下，我只能信任其中一个信息来源。我认为v2ray的信息是更可靠的，因为是你copy而来，也是我亲眼所见的。而custom firewall的信息由你转述而来，也许你用firewall并不够熟练出了差错了呢。
总之，AI提供了数条可能引起你这个问题的原因，知道原因你便可以排障了。
[这里应该是AI提供的方案，因为前面已经给出了，我就不重复了]
因为你有x86-64和树莓派两个linux设备，各方面看起来好像系统时间上出问题的概率更大啊。我之前提过，我有一台banana-pi，我也好你也好，我们都知道这种pi设备和pc设备并不一样，pc的主板中有纽扣电池，在设备断电后也能持续记录时间，而pi设备是没有电池的。如果你的树莓派启动后没有一个联网自动校时程序帮你修正系统时间，vmess协议绝对无法正常工作。

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

v2ray does not work on raspberry pi but works fine on x64 laptop with same config #3378

Uh oh!

{{title}}

Uh oh!

Replies: 5 comments 2 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

v2ray does not work on raspberry pi but works fine on x64 laptop with same config #3378

Uh oh!

VarmRay Apr 10, 2025

Replies: 5 comments · 2 replies

Uh oh!

tomandjerry27 Apr 28, 2025

Uh oh!

tomandjerry27 Apr 28, 2025

Uh oh!

VarmRay May 11, 2025 Author

Uh oh!

tomandjerry27 May 12, 2025

Uh oh!

Uh oh!

VarmRay May 18, 2025 Author

Uh oh!

tomandjerry27 May 19, 2025

Uh oh!

tomandjerry27 May 19, 2025

VarmRay
Apr 10, 2025

Replies: 5 comments 2 replies

tomandjerry27
Apr 28, 2025

VarmRay
May 11, 2025
Author

VarmRay
May 18, 2025
Author

tomandjerry27
May 19, 2025

tomandjerry27
May 19, 2025