TCP connectivity check with firefox portal leads to unexpected result

[Evian-Zhang]

The check_request_tcp_firefox function in crates/shadowsocks-service/src/local/loadbalacing/ping_balancer.rs is used to check TCP connectivity by checking the response of http://detectportal.firefox.com/success.txt whether to be "HTTP/1.1 200 OK\r\n", and this is used to calculate the score of servers, and thus leading to the best server selected by ping balancer.

However, all servers in my server list are granted with score 8000 by sslocal -c config.json -vv, and after checking the detailed log, I found that some servers are unreachable, and is granted with 8000 score, which makes sense. However, other servers are reachable, but the response from firefox is "HTTP/1.1 204 No Content\r\n" (I don't know the policy of Firefox and it's so weird), as a result, those servers are also marked as unreachable and are granted with 8000 score. However, if I manually using those 204-response servers, the proxy does works as expected.

Maybe we should change the checking rule to also includes the "HTTP/1.1 204 No Content\r\n"? (I compile a local version with this change, and it works fine).

在crates/shadowsocks-service/src/local/loadbalacing/ping_balancer.rs中的check_request_tcp_firefox是通过检查http://detectportal.firefox.com/success.txt的响应是否为"HTTP/1.1 200 OK\r\n"来检测TCP连通性的，而这被用于计算服务器的分数，最终被ping均衡器选取最高的分数作为最好的服务器。

但是，我的服务器列表中的服务器的分数均是8000，在检查完详细的日志后，我发现有些服务器访问不了，因此是8000，这是合理的。但是其他服务器其实能访问到，但是firefox返回了"HTTP/1.1 204 No Content\r\n"（我不了解firefox的政策，这很奇怪），因此，这些服务器也被认为无法访问，因此也给了8000分数。但是，如果我手动使用这些返回204的服务器，是能正常工作的。

也许我们应当修改检测规则，同样检查是否为"HTTP/1.1 204 No Content\r\n"？（我本地编译了一个版本，这个版本运行是正常的）

[database64128]

This does not make any sense. Why would anyone respond to a GET request with 204? Are you sure the 204 response is from a legitimate Firefox server?

[Evian-Zhang]

I have no idea. Those servers are not controlled by myself, and all reachable servers in my server list get a 204 response, while when I request the firefox portal from my local machine, the response is 200. Weird...

[Evian-Zhang]

From this superuser answer, it is normal for connectivity checking page to response 204. However, as the url suggests, the detectportal.firefox.com/success.txt should response with a 200 instead of 204. I cannot reproduce the 204 response locally, it seems only occurs in the remote servers.

[database64128]

What about https://detectportal.firefox.com/success.txt?

[Evian-Zhang]

The HTTPS version returns 200 in my local machine as well. The code in check_request_tcp_firefox function suggests that it also connects to the 80 port with plain HTTP instead of HTTPS.

[database64128]

By "from my local machine", did you mean the request went through the proxy (the proxy server selected by ping balancer), or your local ISP?

[Evian-Zhang]

Local machine through ISP: http & https returns 200
Local machine through reachable proxy server: http returns 204; https returns 200

[database64128]

Your proxy servers probably hijack these requests to save bandwidth. You should ask your provider to fix the response code.

[Evian-Zhang]

OK :)

BTW, if someone asked why the best server is always the first server in servers list, one possible reason is here.

[zonyitoo]

Well yes, its true. Firefox's portal should return 200 OK, and Google's portal returns 204 No Content.

But it is true that we cannot be sure that Firefox's portal could never return 204 No Content, so if you actually saw 204 in log, could you goto the server and double check with curl http://detectportal.firefox.com/success.txt and see if it actually returns 204 in your server environment.

If it actually returns 204, please add -v and share the actual IP of detectportal.firefox.com to us.

I am totally welcome to add HTTP/1.1 204 No Content\r\n.

[Evian-Zhang]

@zonyitoo Thank you for your reply.

could you goto the server and double check with curl http://detectportal.firefox.com/success.txt and see if it actually returns 204 in your server environment.

Sorry, but the remote servers are not controlled by myself, and as discussed above, evidence shows that the provider hijacks the portal page to save bandwidth, but returns wrong status code. :(