lige_icon: one icon and rule set shared by several proxy clients

What the repository actually contains

The repository is a personal asset collection with a distribution method, and the README describes it in that order. The project is mainly used to back up and share a personal icon library, routing rules and some plugin configurations, for use with Quantumult X, Loon, Surge, Fileball, Senplayer, Yamby and Hills. The icon content covers commonly used application icons, country and region icons, airport logos and Emby related icons, with more added and updated from time to time. The README carries a timestamp of the last update, 2026-10-19 at 20:51:50, and a total of 1553 icons, which tells you two things at once, that the collection is large enough to be worth sharing and that it is maintained by hand. The repository layout follows the same structure. There is an icon directory, a rule directory for the routing rules, a scripts directory for the plugin and the import pages, a Plugin directory, a jiaochen directory which holds the usage tutorial, and at the root the JSON files themselves, with ligeicon.json for the general set, lige-emby-icon.json for the Emby set, and ligeicon-surge.json for Surge. There is also a Telegram chat linked from the readme, and the author states that the project keeps updating icons, rules and a backup of personal configuration.

Two libraries, split by what you actually run

The first design decision is that there are two sets rather than one, and the split is not arbitrary. The general icon library, which does not include Emby, is the one recommended for proxy software such as QuanX, Loon and Surge, and it is served as a raw file from the repository. The Emby specific library is the one recommended for players, namely Fileball, Senplayer, Yamby and Hills.

https://raw.githubusercontent.com/lige47/lige_icon/main/ligeicon.json
https://raw.githubusercontent.com/lige47/lige_icon/main/lige-emby-icon.json

Both are plain JSON served over a raw GitHub URL, which is what makes the one-click import work at all, since the client fetches the file itself when you follow the link. The reasoning behind the split is easy to reconstruct. A media server front end such as Emby expects the artwork to match its own naming, so an Emby set is large and specific, while the general set is for a proxy dashboard where a small icon per application is what matters. Including Emby artwork in the general set would bloat the file for the majority of users who do not run a media server. If you use more than one of these clients, this is also where the value multiplies, because the same artwork and the same names appear in each of them, so a rule you write once reads the same everywhere.

One-click import, and why each client needs its own URL

The import table is the part of the README that tells you how the clients expect to receive an icon set, and reading the four links tells you a lot about the platforms involved. Quantumult X has an open app URL that points at its own gallery module with the icon type and the set URL encoded in the query, and Loon has an equivalent import endpoint that takes an iconset parameter. The two players, Senplayer and the Xiaohuan player, do not have a native import URL in the same shape, so the project hosts its own import pages on its GitHub Pages site, one for the general purpose import and one called rodel_import, and those pages pass the set URL along. That tells you the integration is a URL that the client opens, and that the project had to write small helper pages for the clients that could not take a set URL directly. A third file, ligeicon-surge.json, sits alongside the two main ones for Surge. For the user the practical effect is that adding the artwork to a client is a single link, and there is no need to download and edit JSON by hand, which is the friction that usually stops people from maintaining a personal icon set at all.

The routing rules, and what they are for

The routing rules are the second half of the project, and there are two of them in the table. One covers the major AI model services, and one covers Emby, and both are served as raw list files.

https://raw.githubusercontent.com/lige47/lige_icon/main/rule/openai.list
https://raw.githubusercontent.com/lige47/lige_icon/main/rule/embytest.list

A list file of this kind is the unit that a proxy client consumes to decide which traffic belongs to which group, and the naming makes the intent clear, since the AI model list is for sending model API traffic down a particular path, and the Emby list is for a media server. The README does not describe the syntax of these lists, the matching rules, or how they are meant to be combined with the client's own configuration, so a reader who wants to know exactly what a list entry does will not find it in this repository. What the repository does give you is the artefact and a stable URL for it, plus a usage tutorial in the jiaochen directory that the readme links for the icons and, by extension, for the rest of the setup. The topic list of the repository names hills, loon, quantumult-x, senplayer and surge, which is the same set of clients the tables cover.

The Loon network check plugin

The Loon section is a small, concrete piece of tooling. It covers entry and landing node information, and notifications about changes to removed IP addresses, and the full version is pointed at a separate Telegram channel. The artefact is a Loon plugin file, referenced with a raw URL.

https://raw.githubusercontent.com/lige47/lige_icon/main/scripts/wangluoxinxi.plugin

Loon plugins are declarative rule files that the client reads, and the name of this one is a transliterated reference to network information. The interesting design choice is that the file is hosted as a raw URL and referenced from elsewhere, rather than being pasted into the configuration, so it can be updated on the server side without touching the device. The README says the full version is in the Telegram channel, which implies the repository holds the standard variant and that a more complete one is distributed through the channel. That is a distribution pattern worth noting if you rely on it, because the artefact you fetch can change without a version change in your configuration. The scripts directory also contains the two import pages used by the players, so the same directory holds both the tool and the files it fetches.

The update cadence, the no-fork request and the missing licence

Two things in the README stand out for anyone deciding how to depend on this. The first is the request at the top, that people should not fork the project, because it continuously updates the icons, the rules and a backup of the personal configuration, and that anyone who quotes or reposts should credit the source. The second is the licence, which is listed as unknown, with no licence file at the top level of the repository. Taken together they describe a curated personal resource rather than an open source project with a contribution model. A fork is not wanted because the value is the maintenance, and a fork would immediately stop receiving it, which is a rational request from the maintainer but an awkward one for a user, because there is no fork to fall back on if the project goes quiet. The release tags are named after dates rather than versions, with v260510 from 2026-05-09, v260108 from 2026-01-08 and v250803 from 2025-08-03, which is another sign of a continuously republished set rather than a versioned package. The last push was on 2026-10-19, the same day as the update timestamp in the readme, so the collection is current, and the readme asks for icon requests to be made in the chat when an icon is missing.

Editorial conclusion

Adopt lige_icon if you run one of the listed clients and want a single maintained icon set with the same artwork in all of them, including the Emby artwork that the general library deliberately leaves out. It does not fit a team that needs icons it controls and can guarantee, because the terms are unstated, the project asks for attribution rather than offering a licence, and the maintainer explicitly does not want forks, so you cannot treat it as an upstream you can pin and vendor. Before you depend on it, read the usage tutorial in the jiaochen directory and check the icon count and update date in the README, since the contents change frequently and the release tags are named after dates rather than versions.

Frequently asked questions

Official sources

1. Issues
2. lige47/lige_icon on GitHub
3. Project website
4. README
5. Releases