Enable flow_enabled for VLESS when inbound encryption is set

[Red0Core]

What

• Refactor flow_enabled calculation in app/core/hosts.py:
  • Keep the existing strict conditions as base_flow_enabled.
  • Additionally set flow_enabled=True for VLESS when inbound encryption is enabled (encryption not in None, "", "none").

Why

Some VLESS setups use VLESS Encryption (e.g. with XTLS Vision) and expect “flow”/optimized behavior to be treated as enabled even when the previous TLS+transport constraints don’t match. This change makes the flag align better with VLESS encryption usage and avoids missing flow in encrypted VLESS configs.

References:

• XTLS VLESS inbound docs (VLESS Encryption):
  https://xtls.github.io/en/config/inbounds/vless.html#:~:text=VLESS%20Encryption%3A%20No%20underlying%20transport%20restrictions.%20If%20the%20underlying%20layer%20does%20not%20support%20direct%20copying%20(see%20above)%2C%20it%20only%20penetrates%20Encryption.
• motivation (VLESS Encryption + XTLS Vision performance):
  https://xraycore.org/en/misc/vless-encryption/#2-%D1%81-xtls-vision-%D0%BC%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F-%D0%BF%D1%80%D0%BE%D0%B8%D0%B7%D0%B2%D0%BE%D0%B4%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C

Verification

• Tested locally using docker compose.
• Confirmed behavior is unchanged when encryption: "none" (in that case flow_enabled still depends only on the original base_flow_enabled conditions).

Notes

• Change is scoped to protocol == "vless" only.
• No impact on other protocols/transports.

Summary by CodeRabbit

• Bug Fixes
  • Updated flow configuration logic to enable flow under broader protocol and encryption combinations.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: bfc99e70-1220-4443-aa03-84e46dcb6ef8

📥 Commits

Reviewing files that changed from the base of the PR and between 3d749e0 and b406bbb.

📒 Files selected for processing (1)

• app/core/hosts.py

---

Walkthrough

The change modifies flow-enabled computation in app/core/hosts.py's _prepare_subscription_inbound_data function to expand flow enablement for VLESS protocol when encryption is configured, beyond the prior constraints.

Changes

Cohort / File(s)	Summary
Flow-enabled Logic Expansion app/core/hosts.py	Modified _prepare_subscription_inbound_data to replace single flow_enabled boolean with base_flow_enabled plus an additional condition that enables flow for protocol == "vless" when encryption is set to any value other than None, "", or "none".

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐰 A flow of logic, refined and bright,
VLESS now dances through the night,
When encryption whispers its sacred code,
The flow takes wing down the digital road,
Simpler rules, yet oh so right! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and concisely describes the main change: enabling flow_enabled for VLESS protocol when inbound encryption is configured.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Copilot]

Pull request overview

This PR adjusts how flow_enabled is derived for subscription inbounds so VLESS inbounds with explicit inbound encryption are treated as flow-capable, even when they don’t match the previous strict TLS+transport constraints.

Changes:

• Split the original strict flow conditions into base_flow_enabled.
• Extend flow_enabled for protocol == "vless" when inbound encryption is set (not None, "", or "none").

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

encryption is pulled directly from inbound_config (defaulting to "none") and is not normalized. The new check encryption not in (None, "", "none") is therefore case/whitespace sensitive (e.g., "None", "NONE", or " none " would be treated as enabled and turn flow_enabled on unexpectedly). Consider normalizing once (e.g., strip + lowercase) before this comparison so the behavior matches the comment intent (“not 'none'”).

Suggested change

	# Enable also when inbound vless encryption is enabled (not "none")
	flow_enabled = base_flow_enabled or (
	protocol == "vless" and encryption not in (None, "", "none")
	normalized_encryption = encryption.strip().lower() if isinstance(encryption, str) else encryption
	# Enable also when inbound vless encryption is enabled (not "none")
	flow_enabled = base_flow_enabled or (
	protocol == "vless" and normalized_encryption not in (None, "", "none")

[Copilot]

The comment says flow is computed “only for VLESS with specific conditions”, but flow_enabled is now also enabled for VLESS when inbound encryption is set. Please update the comment to reflect the full set of conditions so future readers don’t assume tls_value/transport constraints are still required.

Suggested change

	# Compute flow_enabled: only for VLESS with specific conditions
	# Compute flow_enabled for VLESS either when the TLS/transport/header
	# constraints below are met, or when inbound VLESS encryption is set
	# to a non-empty value other than "none".

[ImMohammad20000]

This is not an acceptable behavior for our current setup it need change in panel i m not merging this but i keep it open as reminder to change the behavior in the future

[muffintime77]

Please confirm this PR, as it appears legitimate and does not interfere with the panel's operation, and there are no other ways to enable this mode. Pleeeease?

[mayoroffk]

Great PR! I was actually planning to implement this myself until I came across your work. I’m currently trying to set up a combination of xhttp + vless encryption + xtls-vision, and this functionality is a total blocker for me right now. I don't see any reason why these changes would interfere with the panel's stability, but they definitely solve a huge distribution issue. Really looking forward to seeing this merged soon. Thanks!