[Bug] no-resolve compatibility issue

mashirozx commented 1 month ago

Verify steps

[X] I have read the documentation and understand the meaning of all configuration items I have written, avoiding a large number of seemingly useful options or default values.
[X] I have not reviewed the documentation and resolve this issue.
[X] I have not searched the Issue Tracker for the problem I am going to raise.
[X] I have tested with the latest Alpha branch version, and the issue still persists.
[X] I have provided server and client configuration files and processes that can reproduce the issue locally, rather than a desensitized complex client configuration file.
[X] I have provided the simplest configuration that can reproduce the error I reported, rather than relying on remote servers, TUN, graphical client interfaces, or other closed-source software.
[X] I have provided complete configuration files and logs, rather than providing only parts that I believe are useful due to confidence in my own intelligence.

Operating System

MacOS, Windows, Android

System Version

general issue

Mihomo Version

https://github.com/MetaCubeX/mihomo/commit/38fd37108b22b0e937cae7743c562a2147c65cca

Configuration File

rules:
  - IP-CIDR,192.168.0.0/16,no-resolve

Description

Users used to configure as:

rules:
  - IP-CIDR,192.168.0.0/16,no-resolve

But with the changes in https://github.com/MetaCubeX/mihomo/commit/38fd37108b22b0e937cae7743c562a2147c65cca, such a config style will no longer work with the build of the alpha branch.

I personally understand that - IP-CIDR,192.168.0.0/16,direct,no-resolve is a better format, but there are still a lot of existing rule sets configured in this style, i.e., the famous ACL4SSR.

I think with such a breaking change, we should throw a more conspicuous error message, instead of error: proxy no-resolve not found, and what's more, it's better to provide compatibility for the old style.

Logs

No response

mashirozx commented 1 month ago

cc @wwqgtxx

xishang0128 commented 1 month ago

The format of IP class routing rules has always been type, content, proxy, additional parameters (optional). Are you sure your example is correct?

mashirozx commented 1 month ago

The format of IP class routing rules has always been type, content, proxy, additional parameters (optional). Are you sure your example is correct?

I don't know the history of this, but the rule set I've used for years is in this format, and it works well for a long time:

https://github.com/ACL4SSR/ACL4SSR/blob/master/Clash/Providers/LocalAreaNetwork.yaml#L14-L25

xishang0128 commented 1 month ago

The rule-provider and rules are not the same thing

mashirozx commented 1 month ago

Well, it seems to be pretty much the same thing, incompatible with the old:

https://github.com/MetaCubeX/mihomo/commit/763a127287697fe471f0e643e3bd3f5abfad85e9#diff-eb7196056bcd4b0f538c50fb88e2d11a4c61befa15277a4321a8c0cc95e858dcR82-R84

xishang0128 commented 1 month ago

The rule-provider and rules are not the same thing.

Do not use the content of the rule-provider for rules.

The format of IP class routing rules has always been type, content, proxy, additional parameters (optional).

MetaCubeX / mihomo