Web Panels like 3X-UI are leaking an unimaginable amount of passwords and private keys to the GFW

[RPRX]

https://github.com/net4people/bbs/issues/446#issuecomment-2625123949

I do not know the origin of the dispute

我无法在那个 thread 中回复，所以开一个新的，正好也可以在这里讨论一下这个问题，纯技术而言，这场冲突的根源是：

1. 基于 Xray 的 3X-UI 等面板提供默认的明文 HTTP 访问，这不仅暴露服务器，还使得各种密码、代理私钥等被 GFW 截获
2. 并且 YouTube 上的视频基本都是教世界各地的新手使用 http://ip 访问面板，导致占人数最多的新手处于危险中
3. 所以我要求 3X-UI 等面板禁止公网明文 HTTP，毕竟还有 SSH 端口转发、免费 TLS 证书等，但有些面板无论如何都不改

我认为我的做法是负责任的，是某些面板作者及他们的一部分支持者没研究过反审查，导致他们意识不到问题的严重性，当然这只是尽可能往好的方向想（一开始我都想不到），而往另一个方向想就是另一回事了，在此不表，我希望这个 thread 只讨论技术

但是话说回来技术上也没什么讨论的余地，配置面板，尤其是这种反审查软件的面板，本来就不应该允许用公网明文 HTTP，从第一个 X-UI 出现时这种行为就是完全错误的，现在矫正起来竟然如此艰难，有些面板宁愿停更也不愿删掉公网明文 HTTP

参考 why our community hopes web panels like 3X-UI ban plain HTTP for public network: XTLS/Xray-core#3884 (comment)

---

I was unable to reply in that thread, so I opened a new one, where I can also discuss this issue. Technically speaking, the root cause of this conflict is that

1. Panels such as 3X-UI, which is based on Xray, provide default cleartext HTTP access, which not only exposes the server, but also allows various passwords, proxy private keys, etc. to be intercepted by the GFW
2. And videos on YouTube basically teach novices around the world to use http://ip to access the panel, putting the most numerous group of novices at risk
3. So I demand that panels such as 3X-UI block public HTTP over plaintext. After all, there are also SSH port forwarding, free TLS certificates, etc., but some panels will never change no matter what.

I think my approach is responsible. It is that some panel authors and some of their supporters have not studied anti-censorship, which has caused them to fail to realize the severity of the problem. Of course, this is just thinking in the best possible direction (at first I couldn't even think of it), and thinking in the other direction is another matter. I hope this thread will only discuss technology

But then again, there is really not much room for discussion on the technical side. Configuration panels, especially those for anti-censorship software, should never have allowed cleartext HTTP over the public network in the first place, this behavior has been completely wrong since the first X-UI appeared, and it is surprising that it is now so difficult to correct. Some panels would rather stop updating than delete cleartext HTTP over the public network

Reference why our community hopes web panels like 3X-UI ban plain HTTP for public network: XTLS/Xray-core#3884 (comment)

[APT-ZERO]

It's all are already answered by developers, stop repeating
3X-UI/X-UI or Marzneshin and other panels leaked nothing, they didn't blocked TLS, if having the option to use the panel without TLS is equal to leaking, then you leaked traffic of millions of users to GFW by allowing them to use the non-encrypted VLESS with no TLS (Unlike the Trojan)

All of your accusations are already answered, but you never answered the mentioned questions at https://github.com/net4people/bbs/issues/446#issue-2820663321
you blocked everyone who asked those questions at your github repo or telegram group, why? why never answered those questions?

[patterniha]

first, like vless, we can also use trojan without tls, but this has nothing to do with security,
because anyway connection between browser and final-server is tls-encrypted.

second, changing early-data header name has no effect on cloudflare detection, because anyway in header-value we have base64 of vless/trojan header and vless/trojan headers are easy detectable.

third, quic is not removed, just replaced with xhttp-h3.

fourth, http-panel is real danger It exposes all the information of ordinary users,
and expert-users can edit the code themselves to access http.

In addition, in iran, after opening whatsapp and getting meta ips out of the block,
all services except telegram are accessible with serverless methods, and the panels are slowly losing their necessity.

[sweet-pastry]

@wkrp May I ask why the response towards APT-ZERO was regarded as off-topic, when all that I did was presenting what's considered facts regarding the situation against every fraudulent point APT-ZERO raised? Was it because I was replying to a comment already derailing the discussion?

[wkrp]

Discussion of panels, and ways of accessing them, is on topic, but only if the comments are civil and productive. If not, I will delete this thread as I have now deleted #446 (which I should have done earlier). If you are going to fight, do it somewhere else; here we must work together. Authoritarians love nothing better than when they people they rule fight each other, instead of the people directing their anger at the rulers. I help you in your time of need, as I hope you will help me in mine.

@APT-ZERO, you should know better than to repost a comment that has been moderated. I have temporarily blocked your account from the repository. I understand that interpersonal conflicts are real and cannot just be ignored, but I must see more of an effort to overcome the conflicts, not inflame them.

[wkrp]

@wkrp May I ask why the response towards APT-ZERO was regarded as off-topic, when all that I did was presenting what's considered facts regarding the situation against every fraudulent point APT-ZERO raised? Was it because I was replying to a comment already derailing the discussion?

I think your comment was made in good faith. But yes, I want to stop what I see as an off-topic and unproductive line of discussion. I understand the desire to respond to accusations that are felt as unjust. Our goal is not to see how long we can prolong an argument.

[wkrp]

I don't have much experience with panels. If most online tutorials (e.g. YouTube) demonstrate setting up plaintext access to panels, are there any examples of tutorials that show how to do it in a safer way? With encrypted access, e.g., TLS or SSH? How much more complicated is it?

Is it a question of awareness by users, as well as defaults offered by the software?

[wkrp]

@eaglegolden, please stop. This thread of discussion is not welcome.

[livingfree2023]

I have been using both Xray and 3X-UI panel for years. I love and thank both contributors from the deepest of my heart. Let's stop fighting each other and work together.

My two cents on the issue:
Both author could make the potential risk of HTTP clear and the solution clear. I think a ssh -D 8888 server command and config a proxy in your browser/computer is a very simple step before configuring the panel.
Let every old and new user know about this.

For the general audiences, using HTTP is just making your server an easy target and might cost you money to replace IP/server. Let them know and let them decide.

Censorship is a pressure Gov force on people and they say its for their own good.
Forcing others to do or stop doing something for their own good is kind of similar.
Those are the things you guys fought from the beginning. Don't forget that and work together.

===== Translated by AI ====

我已经使用Xray和3X-UI面板多年。我从心底里爱并感谢这两位贡献者。让我们停止互相争斗，一起合作。

关于这个问题，我的两点意见：

两位作者可以明确HTTP的潜在风险，并提供解决方案。我认为在配置面板之前，使用ssh -D 8888 server命令并在浏览器/计算机中配置代理是一个非常简单的步骤。告诉所有新老用户这一点。

对于普通用户来说，使用HTTP只是让你的服务器成为一个容易攻击的目标，可能会花费你更换IP/服务器的钱。告诉他们这些信息，让他们自己决定。

审查是政府对人民施加的压力，他们说是为了人民的利益。 强迫别人为了自己的利益去做或停止做某事是相似的。这些是你们一开始就为之奋斗的事情。不要忘记这一点，一起合作。

[IMIEEET]

dear wkrp i personally dont consider it pointless arguments as rprx itself did it here again by himself without answering prior question in xray thread he mentioned. i think we can also discuss the technical side that rprx is letting people use plaintext when not doing anything about allowinsecure, vless+no tls. should we also open an issue here that why nginx does not ban plain http in not local binds? or is this leaved to users to decide?

[CrazyBoyFeng]

@IMIEEET I think I can answer part of the query for him.

why nginx does not ban plain http in not local binds?

Because the purpose of nginx is not anti-censorship.

why not doing anything about allowinsecure, vless + no tls.

The insecure option is provided because the connection can be unencrypted when used on an intranet, or when there is an encrypted external transport layer.
xtls has reminded users in the tls documentation and vless documentation that you need to have a trusted transport layer when using these features.

Danger
This should not be set to true in deployments for security reaons, or it can be susceptible to man-in-the-middle attacks.
Danger
Currently, VLESS does not provide built-in encryption. Please use it with a reliable channel, such as TLS.

Also, unencrypted cross-border proxies will not work at all in China and will be quickly blocked by the national firewall, so in fact no Chinese use plaintext cross-border proxies. You might say that Iran's national firewall doesn't censor plaintext, so it can be used that way. Although I don't know why the Iranian government doesn't censor plaintext, because technically it's much easier to censor plaintext than ciphertext. National gateways, ISP gateways can quickly trace or block certain domains, certain keywords if they find them in plaintext packets. But the Iranian government doesn't do that. One speculation is that the Iranian government does not block plaintext in order to peek at the privacy. Of course none of us have definitive proof of this, and it remains only speculation. But just because it hasn't happened yet doesn't mean the risk doesn't exist. The Chinese firewall has already demonstrated that this risk exists. As a known security vulnerability, it is necessary for us to be proactive in patching it. Rather than waiting for news of a vulnerability being exploited by censors or hackers to break before remedying it.
What I'm most puzzled about as an observer in this dispute is: why is pointing out a security vulnerability being blamed?

[RPRX]

@IMIEEET 为什么 Nginx 不禁止明文 HTTP？为什么浏览器不禁止明文 HTTP？因为它们是通用软件，并非针对反审查而设计

himself without answering prior question in xray thread he mentioned

我不确定 prior question 指的是什么，我没有回避过任何问题，只要我看到了我就回答过（APT-ZERO 问的那些搞笑问题除外）

关于 plain VLESS 的话题我也早就回复过：XTLS/Xray-core#3884 (comment)

Secondly, your argument is completely illogical. By this logic, since you exclusively develop the Xray core, and all clients are using this core to connect, while you still haven't equipped the VLESS TCP protocol with encryption or removed it, does that mean you have also been hired by the government to expose people's data?

Because everyone knows that VLESS protocol's encryption is none, if you still want to deploy plain VLESS, it is your own choice.

But when newbies following YouTubers to visit http://ip, they just exposed their data to GFW, even without knowing how to fix it. Then they start using the proxy, with passwords and private keys held by GFW, and they may won't even notice that.

That's the key difference.

并且我在 Telegram channel 中说过，网上关于 VLESS 的教程都是些 REALITY、TLS 等带加密的，而不像面板一样都是些 http://ip

这里最大的区别是“是否自愿”，大量新手是在缺乏相关知识的情况下跟着 YouTuber 访问 http://ip ，而非机场主非要部署明文代理

---

Why doesn't Nginx block plaintext HTTP? Why don't browsers block plaintext HTTP? Because they are general-purpose software and not designed to counter censorship.

himself without answering prior question in xray thread he mentioned

I'm not sure what the prior question refers to, but I have not avoided any questions. I have answered any questions I have seen (except for the silly questions asked by APT-ZERO).

I also replied to the topic about plain VLESS a long time ago: XTLS/Xray-core#3884 (comment)

Secondly, your argument is completely illogical. By this logic, since you exclusively develop the Xray core, and all clients are using this core to connect, while you still haven't equipped the VLESS TCP protocol with encryption or removed it, does that mean you have also been hired by the government to expose people's data?

Because everyone knows that VLESS protocol's encryption is none, if you still want to deploy plain VLESS, it is your own choice.

But when newbies following YouTubers to visit http://ip, they just exposed their data to GFW, even without knowing how to fix it. Then they start using the proxy, with passwords and private keys held by GFW, and they may won't even notice that.

That's the key difference.

And as I said in the Telegram channel, the online tutorials on VLESS are all about REALITY, TLS and other encryption, unlike the panel, which is all about http://ip

The biggest difference here is “voluntary or not”. A large number of novices follow YouTubers to visit http://ip without the relevant knowledge, rather than the airport master deploying the plaintext proxy by force

[RPRX]

@livingfree2023 关键问题是占人数最多的新手并没有“自己决定”的能力，他们只会跟着 YouTuber 访问 http://ip 、难以脱离教程

Censorship is a pressure Gov force on people and they say its for their own good.
Forcing others to do or stop doing something for their own good is kind of similar.
Those are the things you guys fought from the beginning. Don't forget that and work together.

Not similar at all

强制性的 censorship 是首先为了统治者的利益而服务的，而强制性的安全设计是真的 for people's own good，这是本质区别

反审查面板禁止公网明文 HTTP 是最基本的安全设计，我说过，就像你设计手雷要有拉环，开车要系安全带，出太空要穿宇航服

就像现在很多网站会强制 HTTPS，以及 TLSv1.3 移除了 TLSv1.2 中一些不够安全的加密套件，难道这些都是错误的吗？显然不是

---

The key problem is that most beginners do not have the ability to “make their own decisions”. They just follow the YouTubers to visit http://ip and find it difficult to break away from the tutorials.

Not similar at all

Compulsory censorship is first and foremost in the interests of the rulers, while compulsory security design is really for people's own good. This is the essential difference

The anti-censorship panel prohibits cleartext HTTP over the public network as the most basic security design*. As I said, it's like designing a grenade with a pull ring, wearing a seat belt while driving, and wearing a spacesuit when going into space*

Just like how many websites now enforce HTTPS, and TLSv1.3 removes some of the less secure encryption suites in TLSv1.2. Are these all mistakes? Obviously not

[IMIEEET]

@CrazyBoyFeng @RPRX nginx is used everywhere https is about privacy at whole not to be only used in anti-censorship tools no matter if data is sensitive or not, yet nobody wants to remove it because of its flexibility like safe/secure/local. the secure part of http is not about censorship, it does not matter if its a xray web panel, another core web panel or a panel that uses nginx or others as web front. any plaintext panel that contains sensitive data needs https not only this panels. they dont ban http bacause they know the users are not only youtube newbies but actual people who know the difference between good and bad cipher connections. just because the doc says vless encryption is none it does not stop all those newbie to stop using plain vless. i have seen big vpn sellers in telegram in my country that encourage their users to "enable allowinsecure to access secure vpn", in this example both the problematic seller and poor people who use them are in danger, should we also label the op as dangerous? and the xray clients that dont go further and prevent that in their own level? one might say that allowinsecure can be used as debugging purpose but we can make this option in clients to turn off after certain amount to encourage people to stop using it. but rprx, you as a creator of a anti-censorship core cant/should not/most not enforce certain policies to downstream projects like web panles using it. before v2rayn released linux version of client i had to use 3x-ui as a client on my pc but enforcing of https and random webpath is not what i look for in local setup as it keep me from freely using it as i want in the name of freedom. between the privacy and freedom of users there is a narrow line here that a lot of people in this argument are missing, either sticking at one of this two

[RPRX]

@wkrp

I don't have much experience with panels. If most online tutorials (e.g. YouTube) demonstrate setting up plaintext access to panels, are there any examples of tutorials that show how to do it in a safer way? With encrypted access, e.g., TLS or SSH? How much more complicated is it?

Is it a question of awareness by users, as well as defaults offered by the software?

事实上，即使是没有禁止公网明文 HTTP 的面板，在前段时间也加上了对明文 HTTP 不安全的警告，以及 SSH 端口转发的提醒

但他们仍然提供了明文 HTTP 的选项（最方便，相当于默认），且 YouTube 上大量教程都是 http://ip ，而安全访问的教程少得可怜

再加上看这些教程的往往都是些新手，他们人数最多、缺乏相关知识且不会脱离当前教程，能搭好就用，造成大量密钥被 GFW 截获

我们无法纠正网上的所有教程，唯一的办法是从源头禁止公网明文 HTTP，毕竟 SSH 端口转发就一行命令，还有大量免费 TLS 途径

---

In fact, even the panels that do not prohibit cleartext HTTP on the public network have also added warnings about the insecurity of cleartext HTTP and reminders about SSH port forwarding in the past.

However, they still provide the option of cleartext HTTP (the most convenient, which is equivalent to the default), and there are a large number of tutorials on YouTube, all of which are http://ip, while there are very few tutorials on secure access.

Plus, the people watching these tutorials are often novices. They are the most numerous, lack the relevant knowledge, and will use whatever they can get their hands on without thinking about it, causing a large number of keys to be intercepted by the GFW

We cannot correct all the tutorials on the internet, the only way is to ban cleartext HTTP from the public network at the source. After all, SSH port forwarding is just one line of code, and there are many free TLS options

[RPRX]

我认为所有参与这个 thread 的人都应该达成一个基础共识：我所描述的问题切实存在、已经且仍在大量发生，我们需要解决这个问题

@IMIEEET 而你所做的只是在诡辩，要么说 Nginx 怎么不禁用明文 HTTP，要么就是从根源上否认我们需要促使面板改变

Well，我没有权力迫使别的项目做任何事情，而是反审查相关项目的维护者有义务做出改变去解决安全问题，无需来自于别人的压力

@IMIEEET 这是你最大的认知错误

---

I think everyone involved in this thread should reach a basic consensus: the problem I described does exist, has occurred, and is still occurring in large numbers, and we need to solve it

@IMIEEET All you're doing is sophistry, either saying how Nginx doesn't disable plaintext HTTP, or denying from the root that we need to prompt the panel to change

Well, I have no power to force another project to do anything. Instead, it is the maintainers of the project concerned who are obligated to make changes to address security issues, without pressure from others.

@IMIEEET This is your biggest misconception

[RPRX]

@IMIEEET 或者说，就算我不是 Xray 的开发者，而只是一个反审查领域的研究者，就像 @wkrp ，也有权利去促进解决这一问题

这无关 force，无关 violate anyone's freedom，这只是面板的明文 HTTP 已经被大量滥用、需要被解决而已，为什么总有人不懂？

Or, even if I'm not a developer of Xray, but just a researcher in the field of anti-censorship, like @wkrp, I also have the right to help solve this problem

This has nothing to do with force or violating anyone's freedom. This is just the plaintext HTTP on the panel that has been massively abused and needs to be solved. Why can't people understand this?

[IMIEEET]

@IMIEEET 或者说，就算我不是 Xray 的开发者，而只是一个反审查领域的研究者，就像 @wkrp ，也有权利去促进解决这一问题

这无关 force，无关 violate anyone's freedom，这只是面板的明文 HTTP 已经被大量滥用、需要被解决而已，为什么总有人不懂？

You are free to not waste your time and not respond to this as you stated but for the record i dont reject the technical and security research of this matter but it all started when you accused mhsanaei as someone from gov who is deliberately not forcing https.
If you believe in what you say and you dont do this by force do exactly as title of issue in your repo: only list secure web panels, no less no more
Not to accuse those who dont follow your rules and lie, no one is against insecurity specially in this bbs repo

[RPRX]

@IMIEEET 首先我说过 net4people 这个 thread 只是技术讨论，如果你想要争论其它问题可以去 XTLS/Xray-core#3884 (comment)

并且我在那里说过很多次，我不会无端指责别人，我对他们的看法都是基于他们的诡异行为，毕竟你无法保证所有人都是“好人”

First of all, as I said, the net4people thread is for technical discussions only. If you want to argue about other issues, go to XTLS/Xray-core#3884 (comment)

And as I've said many times there, I don't make groundless accusations against people. My opinions of them are based on their strange behaviour. After all, you can't guarantee that everyone is a “good person”.

[RPRX]

@IMIEEET 你时间多的话，不如你提出一个针对当前问题的 有效解决方案？注意是有效，而不是 YouTuber 还能继续教 http://ip

If you have time, why not propose an effective solution to the current problem? Note that it must be effective, not just something where a YouTuber can keep on teaching http://ip

[livingfree2023]

@wkrp

I don't have much experience with panels. If most online tutorials (e.g. YouTube) demonstrate setting up plaintext access to panels, are there any examples of tutorials that show how to do it in a safer way? With encrypted access, e.g., TLS or SSH? How much more complicated is it?
Is it a question of awareness by users, as well as defaults offered by the software?

事实上，即使是没有禁止公网明文 HTTP 的面板，在前段时间也加上了对明文 HTTP 不安全的警告，以及 SSH 端口转发的提醒

但他们仍然提供了明文 HTTP 的选项（最方便，相当于默认），且 YouTube 上大量教程都是 http://ip ，而安全访问的教程少得可怜

再加上看这些教程的往往都是些新手，他们人数最多、缺乏相关知识且不会脱离当前教程，能搭好就用，造成大量密钥被 GFW 截获

我们无法纠正网上的所有教程，唯一的办法是从源头禁止公网明文 HTTP，毕竟 SSH 端口转发就一行命令，还有大量免费 TLS 途径

I agree with RPRX that 3X-UI should do at least something, anything to stop the leaks. I am not familiar with other panels but it sounds like they have a good start.

Let's put 3X-UI aside, say if GFW, who has unlimited money and man-power to develop/bribe a very good panel and find a very influential Youtuber to lure millions of users to this un-intended way of using xray-core, what can we do about it?

1. Maybe we could contact some Youtuber about this, see if they can make a new video about this topic, they will benefit from this new video too.
2. Maybe RPRX could modify xray-core's license to enforce certain usage?

To be honest, none of the above can do much.

In the worst case scenario, a large number of users will leak their private keys and their VPS IP so that GFW can listen to their traffic. I don't think they will leak their gmail passwords or email contents since they are encrypted by browser/client. But their internet history could be leaked. Their own IP addresses can be leaked and with ISP's data, their identities can be traced. That's the biggest issue maybe?

---

我同意RPRX的观点，3X-UI至少应该采取一些措施来阻止泄漏。虽然我对其他面板不熟悉，但听起来他们有一个很好的开端。

先撇开3X-UI不谈，假设GFW有无限的资金和人力来开发/贿赂一个非常好的面板，并找到一个非常有影响力的Youtuber来引诱数百万用户以这种意外的方式使用xray-core，那么我们能做些什么呢？

或许我们可以联系一些Youtuber，看看他们是否可以制作一个关于这个话题的新视频，他们也会从这个新视频中受益。

也许RPRX可以修改xray-core的许可证来强制某些用途？

说实话，以上方法都不太有效。

在最坏的情况下，大量用户将泄露他们的私钥和VPS IP，这样GFW就可以监听他们的流量。我认为他们不会泄露他们的Gmail密码或邮件内容，因为这些都是由浏览器/客户端加密的。但他们的上网历史可能会被泄露。他们自己的IP地址也可能被泄露，通过ISP的数据，他们的身份可以被追踪。这可能是最大的问题？

---

من با RPRX موافقم که 3X-UI باید حداقل کاری برای متوقف کردن نشت‌ها انجام دهد. من با سایر پنل‌ها آشنا نیستم، اما به نظر می‌رسد آنها شروع خوبی داشته‌اند.

بیایید 3X-UI را کنار بگذاریم، بگوییم اگر GFW، که دارای پول و نیروی انسانی نامحدود برای توسعه/رشوه دادن به یک پنل بسیار خوب است و یک یوتیوبر بسیار تاثیرگذار را برای جلب میلیون‌ها کاربر به این روش ناخواسته استفاده از xray-core پیدا کند، ما چه کاری می‌توانیم انجام دهیم؟

شاید بتوانیم با برخی از یوتیوبرها تماس بگیریم، ببینیم آیا آنها می‌توانند یک ویدیوی جدید درباره این موضوع بسازند، آنها هم از این ویدیوی جدید بهره‌مند خواهند شد. شاید RPRX می‌تواند مجوز xray-core را برای اجرای استفاده خاصی تغییر دهد؟ صادقانه بگویم، هیچ‌کدام از موارد بالا نمی‌توانند کار زیادی انجام دهند.

در بدترین حالت، تعداد زیادی از کاربران کلیدهای خصوصی خود و IP VPS خود را نشت خواهند داد تا GFW بتواند به ترافیک آنها گوش دهد. فکر نمی‌کنم آنها رمزهای Gmail یا محتوای ایمیل‌های خود را نشت دهند چون توسط مرورگر/کلاینت رمزگذاری شده‌اند. اما تاریخچه اینترنت آنها می‌تواند نشت شود. IPهای خودشان می‌تواند نشت شود و با داده‌های ISP، هویت آنها قابل ردیابی است. شاید این بزرگترین مسئله باشد؟

[RPRX]

网上流行的搭建私人代理的面板大都基于 Xray-core，其中 3X-UI 是占市场份额最多的，当我促使那些面板进行改变时，我曾经以为 3X-UI 的主要开发者 @MHSanaei @alireza0 会重视并致力于彻底解决这个问题，但他们并不想，反倒是其它面板禁止了 http://ip

注：以上仅为事实陈述，不包含任何引申猜想

Most of the popular panel builders for private proxies on the Internet are based on Xray-core, and 3X-UI is the one with the largest market share. When I urged those panels to make changes, I once thought that @MHSanaei @alireza0, the main developer of 3X-UI, would value and be committed to completely solving this problem. However, they did not want to. Instead, other panels banned http://ip

Note: The above is only a statement of facts and does not contain any extrapolated conjectures.

[developer861]

I agree it is really easy to implement zerossl ip certificate
I don’t know why he is insisting so much on keeping the http
in a twitter thread with some iranian developers he stated that it’s because of compatibility with the previous users but it still doesn’t make sense since giving them a warning for next update and implementing it in next version is really easy

https://x.com/vahidfarid/status/1879379958432502101

[wkrp]

@RPRX I am sympathetic to the argument you are presenting. Defaults matter, and accessibility of documentation matters. If it is true that the easiest path to setting up a circumvention web panel leads to one with a plaintext HTTP configuration, the panel software does not discourage such a configuration, and the tutorials a beginner is likely to find reinforce such a configuration, I agree that is a problem. Developers should strive to provide users with safety in the most common or default configuration. (Even if there is a way for advanced users to disable the default protections.) I agree that whether Nginx or some other software supports plaintext protocols is not relevant.

I continue to feel frustration at your techniques of advocacy. In my view, the approach you are taking is unnecessarily antagonistic, and is itself the source of some of the resistance you are encountering. My perception as an outsider is that, intentionally or not, you are creating a situation where, for your advocacy to succeed, other people must lose face. This has the effect of cementing opposition to the idea, rather than achieving acceptance of it. If a panel adopts secure access protocols in the default configuration, that should not be a "defeat" for the panel developers, but rather a victory for them and everyone else. (Keep in mind that I do not have personal experience with these panels and may be overlooking something important.)

I am not sure I agree with the "only way" of #448 (comment). There may be many small and large steps that can be taken to improve the situation. Think of how Let's Encrypt caused a much greater fraction of the web to become more secure, mainly by offering convenience. Of course, if a releasing a new version of software, with backward-incompatible defaults, is required for security, then at some point its developers must bite the bullet and do it. If upstream developers are (for whatever reason) dead-set against implementing any change, then I'm not sure much can be done, other than advocacy and awareness-raising with users.

On that note, is anyone aware of panel configuration guides that show how to do it in the right way? Most YouTube tutorials give bad advice, you say; are there any that give good advice? Are there any written guides such as "How to set up 3X-UI with an SSH tunnel" or "How to set up 3X-UI with a self-signed TLS certificate"? Can you share links? If there are not, then establishing such a guide could be a good way to make progress. Even if it does not immediately become the default, it will have value for at least some users; but additionally, actually writing down the steps will reveal the major difficulties and points of friction, which can inform decisions by upstream developers to make the process easier.

[RPRX]

@ADimSdfff Some developers in v2fly indeed said that I am from GFW, in fact, they did everything they can to attack me

并且 old XTLS didn't have many issues，影响最大的那篇 xtls- 说法是完全错误的，我早就反驳过。old XTLS 只有一个设计问题是它没有过滤掉 TLSv1.2 的流量，而造成这一问题的原因是 TLSv1.2 协议标准没写但实践中 TLSv1.2 客户端们竟然弄了个明文自增 nonce，我都没想到过还能有这种操作导致别人提出时我都不知道他指的是什么（因为我主要研究的是 TLSv1.3），并且即使这一问题存在，被代理流量的 Client Hello、Server Hello 仍然受到代理层 TLS 加密的保护，也未有报告显示 GFW 特殊封锁了 old XTLS 的流量，反而 GFW 选择了针对更通用的明显特征即 TLS in TLS，而 XTLS Vision 有效规避了 Trojan 的“一天一端口”揭示了这一点，即使没 REALITY

以及，那篇错误的 xtls- 及有开发者详述 nonce 问题并引起广泛关注、我终于理解它指什么 是在我消失之后，否则我会及时处理，而这里的情况是面板开发者仍然在线，他们能够理解当前的严重问题但并没有致力于彻底解决这一问题

还有，SagerNet 的批评者、NekoBox 的开发者曾经指出，那些软件加的 warning 是有针对性的，比如对于全随机数的 SS、VMess，以及 TLS in TLS 的 Trojan 等这些事实上经常被封锁的协议，那些软件并没有加 warning，它们只是针对 old XTLS 加了 warning

就像 sing-box 开发者写的批评 VLESS XTLS 的那篇搞笑文章，他说 old XTLS 一开始就有问题，然而 SS、VMess、Trojan 就不是“一开始就有问题”了吗？他说 REALITY 被伊朗封锁，然而其它加密协议不是早就被了封锁吗？并且他发文时 REALITY 已经坚持了很久、还没被封，后来才在一段时间被封，并且那时伊朗 GFW 有乱封 TLS、波及了很多正常网站的操作。这种断章取义的目的懂的都懂

我此前消失是因为对这里感到失望，一年后我发现 @yuhan6665 想要维护 XTLS/Go，于是我给他发了邮件说不要管那个仓库了，我有个不需要改 TLS 库且能结合 uTLS、解决现有问题的新方案，并与他一同设计了 XTLS Vision，代码由他完成

---

And old XTLS didn't have many issues. The article that had the greatest impact, xtls-, was completely wrong, and I refuted it a long time ago. The only design issue with old XTLS is that it does not filter out TLSv1.2 traffic, and the reason for this problem is that the TLSv1.2 protocol standard does not specify it, but in practice TLSv1.2 clients actually generate a nonce in plaintext. I never thought that there could be such an operation, and when someone else brought it up, I didn't know what he was referring to (because I mainly study TLSv1.3). And even if this problem exists, the Client Hello and Server Hello of the proxied traffic are still protected by the proxy layer TLS encryption, and there is no report that GFW specifically blocks the traffic of old XTLS. Instead, GFW chooses to target the more common obvious feature, TLS in TLS. XTLS Vision effectively circumvents Trojan's “one port per day” revealing this, even if there is no REALITY

And, that erroneous xtls- and the developer detailed the nonce problem and attracted widespread attention, I finally understood what it meant was after I disappeared, otherwise I would have dealt with it in time, while the situation here is that the panel developers are still online, they can understand the current serious problem but have not worked to completely solve it

Also, critics of SagerNet and developers of NekoBox have pointed out that those software-added warnings are targeted. For example, for protocols such as SS and VMess that use fully random data, and Trojan in TLS in TLS, which are in fact often blocked, those software do not add warnings. They only add warnings for old XTLS.

Like the funny article written by the sing-box developer criticizing VLESS XTLS, he said that old XTLS had problems from the beginning, but SS, VMess, and Trojan weren't “problematic from the beginning”? He said that REALITY was blocked in Iran, but weren't other encrypted protocols blocked long ago? And when he posted, REALITY had already been around for a long time and hadn't been blocked yet. It was only blocked for a period of time later, and at that time, Iran's GFW blocked TLS indiscriminately, affecting the operation of many normal websites. Anyone who understands the purpose of taking things out of context understands

I disappeared before because I was disappointed with this place. A year later, I found out that @yuhan6665 wanted to maintain XTLS/Go, so I sent him an email saying to forget about that repository. I had a new solution that didn't require changing the TLS library and could combine uTLS to solve existing problems. Together with him, I designed XTLS Vision, and he completed the code

[RPRX]

@wkrp 我逐段回复：

首先很高兴看到你也认为这是一个需要被解决的 problem 且 Developers should strive to provide users with safety in the most common or default configuration，还有我们经常会听到伊朗人说 TLS 在伊朗受到广泛的干扰而 plain HTTP performs better，这已经明示了伊朗 GFW 正在故意放行并监控明文 HTTP，而大量用户通过明文 HTTP 使用 3X-UI 这样的反审查工具面板则正中他们的下怀，所以我始终无法排除这里面存在伊朗 GFW 的故意推动，无论是 YouTube 上的教程还是其它的，无论如何，不可否认的是如果这一问题持续存在、得不到解决，受益的将只有伊朗以及世界各地的 GFW（还有人认为我来自他们吗？难道我要对自己不利？）

这里的讨论火药味已经比较浓是因为我早在 XTLS/Xray-core#3884 就开始推动面板禁止明文 HTTP，起初我认为这是一个很明显的必要举措且不需要过多讨论，就算用户意识不到，开发者也能意识到，然后可以像 @hiddify-com 一样将安全作为宣传点，这实际上是在帮助这些面板，是一个 win-win 的结局 —— 就像你也意识到这是一个需要被解决的 problem 且解决这个问题是 a victory for them and everyone else 一样。如果是这样这件事早就结束了，但这件事演变至今的关键就在于部分面板开发者（无论出于何种原因）并不像你我一样认为这里存在需要被彻底解决的 problem，即使 SSH 端口转发能如此简单地解决问题、等效地访问面板，还要坚持提供便捷的公网明文 HTTP 选项、坐视它被大量用户继续滥用，并且无法合理地解释他们采取这一决定的原因，所以并非我要创造不必要的对立，而是它本来就没有道理地存在，虽然我确实指责他们收到了 GFW 的资助，但这是我发现他们的决定无法撼动之后的事情。而此前在这里争论过的关于 TLS in TLS 的问题，你是否知道此前他经常在 Xray 的群组中宣传 TLS in TLS 是炒作？还有某位开发者在 twitter 上宣传 TLS in TLS 是骗流量，这都是他们主动挑起的攻击。我认为评论非技术问题的前提是你要先广泛地了解这个问题/冲突。

（前两段是对 @ADimSdfff 回复前写的，因为他的描述存在很多事实错误所以我先回复了他）

Let's Encrypt 确实推动了 HTTPS 的普及，前提是网站主们已经认识到了 HTTPS 是必要的，因为针对 HTTP 的攻击太多了，我震惊于都 2025 年了竟然会有 anti-censorship 领域的开发者不认为强制加密访问面板是必要的，说实话为了彻底扭转形势，可能我们不得不像 Trojan-killer 一样写一个 Panel-killer 以检测明文 HTTP 面板流量并列出他们的密码、代理的私钥来引起整个社区的警觉。但是最终，仍需面板们做出“禁止公网明文 HTTP”的改变，或者伊朗 GFW 率先禁止了它或封 IP 以致引起警觉，但这不太可能发生。

网上已经有一些通过 SSH port forwarding 访问面板的教程，3X-UI 的作者也发布了一个教程视频，但仍然坚持提供公网明文 HTTP。

原因之一或许是此前 3X-UI 发起的一个投票：https://t.me/XrayUI/203

Would you agree to disable HTTP access to the panel, ensuring that if TLS is unavailable, connections are limited to SSH port forwarding or other locally installed solutions such as NGINX? (2176 votes)

• Yes, I agree (37%)
• No, keep HTTP access (47%)
• It doesn't matter (6%)
• Not sure what it is (10%)

我对此的评价是，首先这项投票并未向人们明确解释明文 HTTP 有哪些危害，其次根据这项投票的结果，至少有半数用户依赖明文 HTTP 访问面板，形势相当严峻，最后，我们真的要把这种事情交由大量小白用户决定吗？让我以一个小白用户的独白作为结语：

反正我是理解不了那些 [hidden] 人的脑回路，最开始我是在youtube上看别人的视频一键脚本安装的x-ui面板，http访问，搭建的tls+ws+vmess节点，稳定了一个多月，直到后面突然有一天服务器宕机了（原因是vps商家维护机器了），从这次宕机后就开始觉得自己很菜，因为在排查问题的时候发费了大量时间，一直以为是被墙了。后面我就开始恶补计算机网络，linux，nginx等等知识，基本理清楚了代理的整个过程，我就意识到了https的重要性，开始使用nginx开启https访问反代x-ui面板，那时候完全没有发生R佬争论http明文的事。我想表达的是，不强制使用加密访问面饭，小白绝对会使用默认的http，开发者如果真是为了大家的网络自由，就不应该给小白用户设置默认http明文访问，小白用户哪里懂的什么安全？还有些人说什么你能翻墙就说明就有加密，访问http也没事，防火墙也不知道，你这只是理想情况，你能保证他一直使用代理访问http吗？只要有一次明文的http,防火墙就能记录，你敢为他一直使用代理访问http明文面板打包票吗？

---

@wkrp I will reply paragraph by paragraph:

First of all, I am very glad to see that you also think this is a "problem" that needs to be solved and that "developers should strive to provide users with safety in the most common or default configuration". Also, we often hear Iranians say that TLS is widely interfered with in Iran and plain HTTP performs better. This has made it clear that the Iranian GFW is deliberately releasing and monitoring plaintext HTTP, and the fact that a large number of users use anti-censorship tool panels such as 3X-UI over plain HTTP is exactly what they want, so I can't rule out the possibility that the Iranian GFW is deliberately promoting this. Whether it's a tutorial on YouTube or something else, in any case, it's undeniable that if this problem persists and is not solved, the only ones who will benefit are Iran and GFWs around the world (does anyone think I'm from one of them? Am I supposed to speak against my own interests?).

The discussion here has become more heated because I started pushing for explicit HTTP blocking on panels as early as XTLS/Xray-core#3884. At first, I thought it was a very obvious necessary move that didn't require much discussion. Even if users don't realize it, developers can. Then they can use security as a selling point, just like @hiddify-com. This is actually helping these panels, and it's a "win-win" — just as you realize that this is a "problem" that needs to be solved and solving this problem is "a victory for them and everyone else". If that were the case, this matter would have been over a long time ago, but the key to how this matter has evolved to date is that some panel developers (for whatever reason) do not think that there is a "problem" that needs to be completely solved, just as you and I do. Even though SSH port forwarding can solve the problem so simply, providing equivalent access to the panel, and insisting on providing a convenient public network cleartext HTTP option, and let it continue to be abused by a large number of users, and they cannot reasonably explain the reasons for their decision. So it's not that I want to create unnecessary confrontation, but it just doesn't make sense to exist. Although I do accuse them of receiving funding from the GFW, this is after I found that their decision cannot be shaken. And regarding the issue of TLS in TLS that has been debated here before, did you know that he often promoted TLS in TLS as hype in the Xray group before? And a certain developer tweeted that TLS in TLS was a traffic scam. These are all attacks they initiated. I think the prerequisite for commenting on non-technical issues is that you first have a broad understanding of the issue/conflict.

(The first two paragraphs were written before replying to @ADimSdfff, because his description contained many factual errors, so I replied to him first.)

Let's Encrypt has indeed promoted the popularization of HTTPS, provided that website owners have already realized that HTTPS is necessary because there are too many attacks against HTTP. I am shocked that in 2025, there are still developers in the anti-censorship field who do not think that it is necessary to force encrypted access to the panel. To completely reverse the situation, perhaps we have to write a Panel-killer like Trojan-killer to detect plaintext HTTP panel traffic and list their passwords and proxy private keys to alert the entire community. But in the end, the panels still need to make the change of “prohibiting plaintext HTTP on the public network”, or the Iranian GFW will take the lead in banning it or blocking IPs, which will cause alarm, but this is unlikely to happen.

There are already some tutorials online on accessing the panel via SSH port forwarding, and the author of 3X-UI has also released a tutorial video, but still insists on providing cleartext HTTP over the public network.

One of the reasons may be a previous poll initiated by 3X-UI: https://t.me/XrayUI/203

Would you agree to disable HTTP access to the panel, ensuring that if TLS is unavailable, connections are limited to SSH port forwarding or other locally installed solutions such as NGINX? (2176 votes)

• Yes, I agree (37%)
• No, keep HTTP access (47%)
• It doesn't matter (6%)
• Not sure what it is (10%)

My comments on this are as follows: firstly, this poll does not clearly explain to people the dangers of cleartext HTTP; secondly, according to the results of this poll, at least half of users rely on cleartext HTTP to access the panel, which is quite serious; and finally, do we really want to leave this kind of thing to a large number of novice users to decide? Let me conclude with the monologue of a novice user:

Anyway, I can't understand the thinking of those [hidden] people. At first, I watched someone else's video on YouTube and installed the x-ui panel with one-click scripting. It accessed the http and set up the tls+ws+vmess node, and it was stable for more than a month, until one day the server suddenly went down (because the vps merchant was maintaining the machine). After this downtime, I began to feel very incompetent, because I spent a lot of time troubleshooting the problem and kept thinking that I was being blocked. After that, I started to make up for lost time by learning about computer networks, Linux, nginx, and so on. I basically figured out the whole process of proxying, and I realized the importance of HTTPS. I started using nginx to enable HTTPS access to the anti-generation x-ui panel. At that time, there was no debate at all about old R arguing about HTTP cleartext. What I want to say is that if encrypted access is not mandatory, novices will definitely use the default http. If developers really want to protect everyone's online freedom, they should not set the default http access to clear text for novice users. After all, what do novice users know about security? Some people say that if you can get past the firewall, it means there is encryption, and it's fine to access http. The firewall doesn't know either. This is just an ideal situation. Can you guarantee that he will always use a proxy to access http? As long as there is a plaintext http once, the firewall can record it. Do you dare to guarantee that he will always use a proxy to access http in plaintext?

[wkrp]

Thanks for taking the time to answer people's questions. And thanks to everyone engaging respectfully. @fodhelper, I appreciate the links to tutorial videos, that helps me understand.

I don't want to see accusations of developers being GFW agents. If that kind of thing has already happened elsewhere, let's not bring it here.

It's not an immediate solution, but there are research opportunities here, in evaluation, measurement, and usable security. As far as I know, no one has yet done a research study on circumvention panels, despite it being an important topic. Researchers, here are some project ideas: examine a panel for security vulnerabilities; run scans to measure the prevalence and detectability of different types of panels; do a usability study to find common misconfigurations and misunderstandings. (And if you do any of these, make sure to communicate with the panel developers—don't blindside them with a finished publication.)

[fodhelper]

allowInsecure and pin certificates are both features derived from v2ray-core, and the former is about five years older than the latter

so what, HTTP support is also derived from the original X-UI

I did consider completely removing the allowInsecure option, but there are still some special uses that really require this option

Then limit it to VMESS and SS, if connection must go from an insecure tunnel then it must be encrypted

This is not to mention the severity of the problem with http://ip/, which does not set any threshold and can be abused by simply recording traffic to obtain data by default.

Your scenario is that GFW records Panel data and scrapes Private Keys and decrypt REALITY traffic
I say GFW does not need to do it when they can easily record all VLESS non TLS traffic without trying to decrypt anything
which one is more likely to happen?

In addition to the numerous VLESS REALITY/TLS tutorials, you can of course find YouTubers teaching VLESS non-TLS examples, but the situation with the panel problem is the exact opposite.

No, most of persian tutorials are VLESS non TLS, but you may find some others
Am i persian or you? I see everyone is using VLESS non TLS, they all get TLS for panel because clients does not support non TLS subscription URL, but they all use VLESS non TLS as there is no limit and it's faster and more lightweight because there is no encryption

When a user adds a wrong header or ALPN, Xray-core fixes it automatically
Why don't you do the same for security of users?
just limit non-TLS VLESS and Trojan to private ip ranges And disallow allowInsecure option for VLESS and Trojan

[dyhkwong]

examine a panel for security vulnerabilities; run scans to measure the prevalence and detectability of different types of panels

It is good for someone to do some security researches on this. However, don't call something beyond the security model a "security vulnerability". Tor does not hide the fact you are using Tor, but it is not a security vulnerability of Tor. Browsers allow users to enter password in HTTP websites and store passwords in cleartext, but it is not a security vulnerability of the browsers. So are those panels. The issue OP mentioned is obviously not a "security vulnerability".

[RPRX]

@fodhelper 我给你展示一下位于中国的情况：

1. https://www.youtube.com/watch?v=SpxTFes1B8U 这个视频发布于 2023 年，我就是看了这个视频才意识到面板问题
   即使这个视频访问 X-UI 是 http://ip ，第一个部署的却是 VMess+WS，当时这个方法能钻 GFW 的空子，后来不行了
   我想表达的是，由于经历过明文 HTTP 被审查的时期，几乎所有中国人都知道明文代理不可取、至少要有某种程度的加密
   不过由于 VMess 是静态密码的对称加密，GFW 记录明文面板流量即可解密后续的代理流量，也能记录 REALITY 私钥并 MITM
2. https://www.youtube.com/watch?v=wd2DpDyCN0c 在我们争论面板问题之后，同一个 YouTuber 发布于去年的视频
   这个视频说明了明文 HTTP 访问面板的危害，并展示了如何通过 SSH 端口转发访问 3X-UI，以及如何申请免费 TLS 证书
3. https://www.youtube.com/watch?v=GB_SHmqotzQ 同一个 YouTuber 于上个月发布的视频，展示了 XHTTP 及上下行分离
   在这个视频中，为了方便仍然是使用 http://ip 访问 3X-UI，而这恰恰就是 3X-UI 不彻底禁止明文 HTTP 所造成的局面

关于伊朗的情况我没有太多的了解，需要更多伊朗人确认，当然我也难以想象，如我说几乎所有中国人都知道明文代理不可取

并且我觉得我们在这里不是为了要比烂，即使你说的情况为真也不代表面板问题不需要得到解决，当然我也可以深入调查并着手解决 VLESS non-TLS 问题，虽然仅靠 Xray-core 的话效果可能有限，如果你们就是想继续部署 non-TLS 代理则没有人拦得住

你可能会说即使面板全删了 http://ip ，反正伊朗人都是部署 non-TLS 代理，那中国人呢？至少中国人需要面板们删掉 http://ip

---

@fodhelper Let me show you what the situation is like in China:

1. https://www.youtube.com/watch?v=SpxTFes1B8U This video was released in 2023, and it was from watching this video that I became aware of the panel issue
   Even though the video accessed X-UI at http://ip, the first deployment was VMess+WS. At that time, this method could get around the GFW, but not anymore
   What I want to say is that because of the period when cleartext HTTP was censored, almost all Chinese people know that cleartext proxies are not desirable and that there should at least be some degree of encryption
   However, since VMess is symmetric encryption with a static password, the GFW can decrypt subsequent proxy traffic by recording the cleartext panel traffic, and it can also record the REALITY private key and MITM.
2. https://www.youtube.com/watch?v=wd2DpDyCN0c After we debated the panel issue, the same YouTuber posted a video last year
   This video explains the dangers of plaintext HTTP access to the panel, and shows how to access 3X-UI via SSH port forwarding and how to apply for a free TLS certificate
3. https://www.youtube.com/watch?v=GB_SHmqotzQ A video posted by the same YouTuber last month shows XHTTP and the separation of upstream and downstream
   In this video, in order to facilitate access to 3X-UI, which is still done using http://ip, which is precisely the situation created by 3X-UI's failure to completely ban cleartext HTTP

I don't know much about the situation in Iran, and I need more Iranians to confirm. Of course, I can't imagine that, as I said, almost all Chinese people know that cleartext proxies are not desirable

And I don't think we're here to argue about who's worse. Even if what you said is true, it doesn't mean that the panel problem doesn't need to be solved. Of course, I can also investigate in depth and start to solve the VLESS non-TLS problem. Although the effect may be limited if you rely solely on Xray-core, if you just want to continue deploying non-TLS proxies, no one can stop you.

You may say that even if you delete all the panels http://ip, the Iranians are still deploying non-TLS proxies, so what about the Chinese? At least the Chinese need the panels to delete http://ip

[RPRX]

@dyhkwong 我觉得每个看了讨论的人都知道这里的安全问题指的是面板不删 http://ip 且它已被 YouTuber 和人们滥用，是两者叠加

至少有一点是可以肯定的，如果面板使 http://ip 的困难程度高于 SSH port forwarding / 免费 TLS 证书，则绝大多数人会转向后者

现在的问题就在于占市场份额最大的 3X-UI 把 http://ip 弄成了最没有门槛、最方便的选项，这就是在坑小白，也确实有很多人在用

@dyhkwong I think everyone who has read the discussion knows that the security issue here refers to the fact that the panel does not delete http://ip and it has been abused by YouTubers and ordinary people, which is a two-fold problem.

At least one thing is certain: if the panel makes http://ip more difficult than SSH port forwarding / free TLS certificates, then the vast majority of people will turn to the latter.

The problem now is that 3X-UI, which has the largest market share, has made http://ip the option with the lowest barrier to entry and the most convenience. This is a trap for newbies, and indeed, many people are using it.

[fodhelper]

I need more Iranians to confirm it.

Isn't #448 (comment) samples enough? and it harms no one if you prevent unsafe setups, even if it be unpopular still it's better to prevent it

And I think we are not here to compare the worst. Even if what you said is true, it does not mean that the panel problem does not need to be solved

I am at your side, they must do what Marzban developer did, limited HTTP to private ip ranges
If i ask you to block unsafe setups, it's just to point an double standard of you, you ask them to prevent useless unsafe plaintext option from panels, but you do nothing yourself about a bigger problem that is in your full control
Just limit non-TLS VLESS and Trojan to private ip ranges And disallow allowInsecure option for VLESS and Trojan
this will harm no one but helps Xray and Panel users a lot, even the experienced proxy providers provide VLESS non TLS to use less server resources on encryptions, if next v2rayNG and other clients be not able to connect to unsafe configs, then proxy providers will also switch to TLS or encrypted protocols instead

Although the effect may be limited if I rely on Xray-core alone, if you just want to continue to deploy non-TLS proxy, no one can stop you.

Also if someone wants to setup a proxy panel without TLS no one can stop them, super easy to bypass such restrictions
Does it mean that there is no need for panel developers to remove HTTP support?

[RPRX]

@fodhelper Double standard？你不觉得我作为一个中国人的视角听到伊朗人连 VLESS non-TLS 都滥用会有点难以置信吗？

YouTube 需要登录才能观看视频，所以你列出的视频以及我列出的视频，我刚刚都没有看。

要我解决一个问题的前提是那个问题确实存在，我确实可以将非加密流量限制在 private network，并通过环境变量启用公网。

但这并不像其它面板已经改变、几乎只剩 3X-UI 不改，你能保证其它流行的 core 会做同样的事情吗？

@fodhelper Double standard? Don't you think it's a bit unbelievable for me, as a Chinese person, to hear an Iranian person abuse even VLESS non-TLS?

YouTube requires login to view videos, so I haven't watched the videos you listed or the ones I listed.

In order for me to solve a problem, the problem must exist. I can indeed restrict unencrypted traffic to the private network and enable public access via an environment variable.

But this is not the case with other panels that have been changed, leaving almost only the 3X-UI unchanged. Can you guarantee that other popular cores will do the same thing?*

[fodhelper]

I don't know if other cores will follow or not
but as most of popular proxy clients are based on Xray-core, it's not a big problem if others don't follow

[RPRX]

@fodhelper 在 GUI client 方面显然 Clash 系的市场份额更大，许多用户本来就在用 Clash，it's not not a big problem

It's clear that Clash has a larger market share in terms of GUI clients, and many users are already using Clash. It's not a big problem.

[RPRX]

@fodhelper 或者我这么说吧，你不用只在这里建议，你去建议 mihomo 和 sing-box 和 v2fly 做出同样的事情，达成一个共识

由于流行的面板都基于 Xray-core，我还是有一些建议的能力的，现在几乎只剩 3X-UI 不改，它改了拼图就基本补全了

Or let me put it this way, you don't just have to suggest it here, you should suggest that mihomo, sing-box and v2fly do the same thing and reach a consensus.

Since popular panels are all based on Xray-core, I still have some ability to make suggestions. Now, almost the only thing left is the 3X-UI, which is basically complete if it is changed.

[fodhelper]

In terms of GUI client, the Clash system has a larger market share

As most of panels are based on Xray, and Mux.Cool is supported by no core except Xray-core, many of users are using Xray based clients
And as XHTTP & Noise features of Xray-core are getting more popular everyday and SB/ClashMeta don't want to support them, there is no choise but Xray based clients
Let's add Tun feature to Xray-core and see how Xray-core will be the most popular on all operation systems

And for 3X-UI problem, you can ask v2rayNG to not allow non TLS Subscription, i promise you everyone will switch to TLS even all of 3X-UI users, because all of them uses Subscriptions even if they use 3X-UI for personal usage only

[RPRX]

我都没想到在伊朗会是这种情况

事实上近期我正准备推出 VLESS 的 encryption，我认为这是一个逐步限制 VLESS non-TLS 的好时机，如果滥用确实存在的话

我唯一担心的事情是到时你们会发现伊朗 GFW 会封锁 VLESS encryption + WS，却不封锁 VLESS non-TLS + WS，就搞笑了

I didn't even think it would be like this in Iran.

In fact, I was about to launch VLESS encryption recently, and I think this is a good time to gradually restrict VLESS non-TLS, if misuse does exist.

The only thing I'm worried about is that you will find that the Iranian GFW will block VLESS encryption + WS, but not VLESS non-TLS + WS, which is just ridiculous.

[fodhelper]

I feel like an protest against the government is close to happen in Iran
they will block all types of proxies even normal websites with high traffic
or turn internet to intranet, who knows
But after this, i don't know what will happen

[RPRX]

不像你们，我觉得包括我在内的大多数中国人对自己的生活还算满意，但是我们会反感言论审查 —— 任何人类都会本能地反感

言论自由是推动社会进步的基础，许多社会问题正是通过新闻曝光的方式得到了解决，或许有一天中国在这方面会有所进步

Unlike you all, I think most Chinese people, including me, are quite satisfied with their lives, but we resent censorship – it is instinctive for any human being.

Freedom of speech is the foundation for social progress. Many social problems have been solved through exposure in the news. Perhaps one day China will make progress in this regard.

[TheLordOfTheKings]

我都没想到在伊朗会是这种情况

事实上近期我正准备推出 VLESS 的 encryption，我认为这是一个逐步限制 VLESS non-TLS 的好时机，如果滥用确实存在的话

我唯一担心的事情是到时你们会发现伊朗 GFW 会封锁 VLESS encryption + WS，却不封锁 VLESS non-TLS + WS，就搞笑了

I didn't even think it would be like this in Iran.

In fact, I was about to launch VLESS encryption recently, and I think this is a good time to gradually restrict VLESS non-TLS, if misuse does exist.

The only thing I'm worried about is that you will find that the Iranian GFW will block VLESS encryption + WS, but not VLESS non-TLS + WS, which is just ridiculous.

Hi @RPRX , non-TLS VLESS is essential for CDN to Origin connections, like for domain fronting.
Anyway, you mentioned Vision Seed and VLESS Seed earlier back in 2024, is it still a thing or they all are going to be merged in the new VLESS implementation?
Can you give us a bit more information about the future development of Xray-core?
Again thanks for your efforts and contributions.

[fodhelper]

Hi @RPRX , non-TLS VLESS is essential for CDN to Origin connections, like for domain fronting.

Don't worry bro, if RPRX decide to limit insecure outbounds, he can do it in one minute
If he did nothing yet, it means he don't want to.
Enjoy with non-TLS VLESS, but don't try to find benefits for this insecure combination

[RPRX]

@TheLordOfTheKings

会受到限制的只是 VLESS without any encryption outbound，而 CDN to Origin 不受影响

接下来一段时间 Xray-core 的重点是 Vision Seed 和 VLESS encryption，然后是 Windows Tun 和 GUI client

The only thing that will be restricted is VLESS without any encryption outbound, while CDN to Origin will not be affected

In the next period of time, Xray-core's focus will be on Vision Seed and VLESS encryption, followed by Windows Tun and GUI client

@fodhelper

我不知道这里有什么值得你阴阳怪气的，我现在确实计划在 VLESS encryption 推出后限制 VLESS without any encryption

这完全只是为了限制你们伊朗人的错误用法，因为中国人本来就会确保自己使用的代理具有某种形式的 encryption

I don't know what's so funny here. I do plan to restrict VLESS without any encryption after VLESS encryption is launched

solely to restrict misuse by you Iranians, because Chinese people would have ensured that the proxy they use has some form of encryption

[fodhelper]

I do plan to limit VLESS after VLESS encryption is launched
This is just to limit the wrong usage of you Iranians, because the Chinese would have made sure the agent they use had some form of encryption

Why? Is there anything wrong with VMess? are you working on VMess-killer?

If security of people matter then it must be a priority
No offense but i feel all you care is making VLESS more popular at any cost
maybe X-UI forks also did not removed HTTP support, to not lose any User, and stay popular

And as you said Chinese don't use non-encrypted, so disallowing insecure configs will not affect them
I don't understand that what is stopping you to disable insecure right now

[RPRX]

VMess 的加密是静态密码+对称加密，拿到客户端密码就能解密以前、以后的所有流量

VLESS 的加密是抗量子密钥交换+对称加密，且具有前向安全，我还能让它做到不牺牲 RTT

VMess encryption is static password + symmetric encryption, and you can decrypt all previous and future traffic once you have the client password

VLESS encryption is quantum-resistant key exchange + symmetric encryption, and it is forward-secure. I can also make it so that RTT is not sacrificed.

[fodhelper]

I know, i remember your comments at v2ray or shadowsocks repository about the idea
But VLESS encryption can take half a year to complete and even more to debug, until then VMess is a good temporary solution for those people who don't use TLS or uses TLS with allowInsecure enabled
And it's funny that you say no Chinese use non-encrypted configs, does Xray have telemetry?
Just disallow non-encrypted outbounds and then you will find that how many people were using it even in China

[RPRX]

你听谁说的需要那么久？VLESS encryption 去年就写了一部分了，这个月内就出，鉴于你们可能喜欢滥用 non-TLS

Who told you it takes that long? VLESS encryption was partially written last year and will be released within this month, in light of the fact that you may like to abuse non-TLS

are you working on VMess-killer?
does Xray have telemetry?

鉴于你的这些，以及在 MHSanaei/3x-ui#2651 等处的阴阳怪气令人生厌，所以你被我 block 了，就像我早就在 Project X 做的一样

In view of your obnoxious and weird behavior, such as at MHSanaei/3x-ui#2651, you are blocked by me, just as I have already done on Project X.

[mikozzuu]

Why? Is there anything wrong with VMess? are you working on VMess-killer?

If security of people matter then it must be a priority No offense but i feel all you care is making VLESS more popular at any cost maybe X-UI forks also did not removed HTTP support, to not lose any User, and stay popular

And as you said Chinese don't use non-encrypted, so disallowing insecure configs will not affect them I don't understand that what is stopping you to disable insecure right now

你们面板不是服务新手吗，一个包装还对 xray 核心来指手画脚了。看你刚才还要和 nginx 比比 HTTP，我都怕你们明天就要拿这个面板来取代 openssl 了

Aren't you newbies in terms of panels? One of your packages is even telling you how to use the X-Ray core. Just now, I saw that you were comparing HTTP with nginx, and I was afraid that you would replace openssl with this panel tomorrow

[mikozzuu]

If security of people matter then it must be a priority No offense but i feel all you care is making VLESS more popular at any cost maybe X-UI forks also did not removed HTTP support, to not lose any User, and stay popular

And as you said Chinese don't use non-encrypted, so disallowing insecure configs will not affect them I don't understand that what is stopping you to disable insecure right now

你也别怪我们中国 xray 用户多嘴，你们都觉得 xray 不安全了，又舍不得自己手里那点用户，干嘛不自己开发一个以“纯HTTP友好”为卖点的核心呢，和你们的面板结合在一起，谁不让你们用HTTP了？

依我看怎么都是双赢，你用你的 HTTP，我们用我们的 xray-core，你也不需要榨干自己的脑袋去寻找专业软件们的 insecure config

所以你怎么还不去给你热爱的 XUI 进行 pull request，开发一款核心呢？不想被人“指点”，你当然可以自食其力，虽然是比吃现成的辛苦了点，但你们不是想留住用户嘛？只支持一个你们最热爱的明文 HTTP proxy，不是更加完美契合你们面板的 style？

Don't blame us Chinese xray users for talking. You all think xray is insecure, but you don't want to lose your users. Why not develop your own core with “pure HTTP friendliness” as the selling point, and combine it with your panel? Who is going to stop you from using HTTP?

From my point of view, it's a win-win situation for everyone. You use your HTTP, we use our xray-core, and you don't need to rack your brains to find insecure configurations in professional software.

So why don't you go and make a pull request for your beloved XUI and develop a core? If you don't want to be “pointed out”, you can certainly be self-reliant. Although it's a bit more work than just using what's ready-made, you do want to retain users, don't you? Wouldn't it be a perfect fit for the style of your panel to only support the plaintext HTTP proxy you love the most?

[CrazyBoyFeng]

it's funny that you say no Chinese use non-encrypted configs, does Xray have telemetry?

This issue has actually been discussed many times above, and we're 100% sure that no Chinese people use unencrypted proxies. The reason for this is because unencrypted proxies expose the domain name, ip, proxy protocol and other information about the access, and when this information is detected by the national firewalls and matches their censorship lists, the connection will be blocked. Therefore, it is both a fact and common knowledge that everyone in China knows that unencrypted proxies do not work in China.

I still don't understand where your anger comes from. We thought we were alerting you to a security issue out of goodwill and concern.

By the way, someone above said don't call it a security issue if you don't have a CVE certification. To that I would say it's not that hard to get a CVE number, just write a brief to some CNA organization describing the process of how the key was leaked on the gateway, and there's a good chance you'll get a CVE, but it's going to be a long process. We don't want to see more connections blocked and more people arrested while waiting for a CVE. That's why we sent out the alert first. Of course, even if there is a CVE, developers are free to not claim it. Its authority isn't much different from ours, and neither is mandatory.

[RPRX]

不用跟 @fodhelper 废话了，他本来就是阴阳怪气、混淆视听的，我在 Project X block 他是因为 XTLS/Xray-core#3884 (comment)

There is no need to argue with @fodhelper. He is inherently ambiguous and confusing. I blocked him on Project X because XTLS/Xray-core#3884 (comment)

We look forward to the release of the new update as soon as possible. We wish you success

Not before he destroy all Xray based panels or get 30k in his wallet lol

或许我应当同步 Project X 和我的 block 列表，这种人实在太烦了

Maybe I should sync Project X with my block list. People like that are just so annoying.

[mikozzuu]

@RPRX 没办法，到了现在，还这么多把面板和底层程序混为一谈，不肯认清面板是 xray 的新手引导，本身是作为文档的小白替代品而存在，却偏偏要把陷阱选项做的最容易访问，最后再来一句“nginx 能不加密凭什么我们不能”、“http是自由”，把自己抬高的跟底层设施似的，看的心里着急

第一次看到有拿 vless 加密说事的就搞笑，道理讲不过、就找对方身上的攻击点的思维遗毒还是来了代理圈，这么久过去了，他们还是只能拿这点说事。果然他们已经是没啥好说的了：）这些人最需要认清三点：1) 面板服务的是谁？是新手 2) 新手搭建的目的是什么？是反审查 3) 作为 文档的一键式小白替代，面板必须干什么？是杜绝错误配置的可能。一个 HTTP 出来，用户的核心配置文件再安全，也全在面板这一关毁了。

现在他们的借口是怎样的呢：1) 面板服务的是谁，他们不在意，或者装不知道 2) 面板用户的目的是什么，他们不在意，或者装不知道 3) 那面板需要做什么？他们觉得什么也不用限制，即便 HTTP 最一键、最广为 YouTube 视频传播，也一定宁可“用户责任自负”，都不愿意守好新手这第一关。也许又要有人说了，说 “没人规定面板就新手能用，没人规定用户用它反审查、还是把数据至于危险境地，它完全应该和底层核心、各种基础设施一样，提供危险的选项，新手栽了跟头也是他自己的教训，犯几回错才知道改” 。我想，他们也许就是自己已经过了新手这个阶段，他们也完全不在意新来的小白处于何种境地。这是我们和他们的最大分歧。

---

There's no way. Even now, there are still so many people who confuse the panel with the underlying program and refuse to recognize that the panel is Xray's newbie guide. It exists as a substitute for document novices, but they deliberately make the “traps” option the easiest to access. And finally, they say, “If nginx can do without encryption, why can't we?” and “http is free,” as if they were elevating themselves to the level of the underlying infrastructure. It makes me anxious to see it.

It's funny to see someone using vless encryption as an argument for the first time. If you can't argue with reason, then the legacy of the thinking that looks for the other person's weak points has come to the proxy world. After so long, they can still only use this as an argument. Sure enough, they have nothing more to say :) These people need to recognize three things: 1) Who is the panel serving? It's for beginners. 2) What is the purpose of the setup for beginners? Anti-censorship. 3) As a one-click newbie replacement for the documentation, what must the panel do? Prevent incorrect configuration. One HTTP error and the user's core configuration file, no matter how secure, is completely destroyed at the panel level.

Now what is their excuse: 1) They don't care who the panel serves, or they pretend not to know. 2) They don't care what the panel user's purpose is, or they pretend not to know. 3) So what does the panel need to do? They feel that nothing needs to be restricted. Even if HTTP is the most convenient and most widely used for spreading YouTube videos, they would rather “let the user take responsibility for themselves” than guard this first barrier for novices. Some people may say, “No one says that the panel is only for novices, no one says that users should use it to counter censorship or put data at risk. It should be like the underlying core and various infrastructures, providing dangerous options. If a newbie makes a mistake, it's his own lesson, and he won't know how to improve until he makes a few mistakes.” I think they have probably already passed the stage of being a newbie, and they don't care about the situation of newbies at all. This is the biggest difference between us and them.

[wkrp]

Thanks to people keeping the conversation on-topic and productive.

I must ask that participants please not make arguments based in nationalism; e.g. China vs. Iran. Remember the loudest users are not always representative of most users.