Usque Custom Pro: a browser-based WARP MASQUE config generator
基于 Cloudflare WARP / MASQUE 的可视化注册、配置生成与多客户端转换工具。 生成、Clash/Mihomo 智能分流、Shadowrocket、sing-box、本地 VLESS 桥接,以及可选的 WARP 出口检测。
At a glance
- What is it?
- Usque Custom Pro registers a Cloudflare WARP MASQUE device in the browser, keeps the native config.json as the source of truth, and exports Clash, sing-box, Shadowrocket and VLESS output. It is a convenience layer, not a way to pick your exit country.
- Who is it for?
- Adopt Usque Custom Pro if you want a MASQUE device registered without hand-building a config, and you intend to keep the resulting config.json as your long-lived credential file. Skip it if you expect node count to buy you distinct exits or extra quota, or if you need a documented licence before shipping it inside a company.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 9 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 16, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Usque Custom Pro actually removes from the workflow
The problem it targets is narrow and real. Registering a WARP MASQUE device by hand means generating a P-256 key, submitting a public key to the enroll endpoint, and then assembling a config file whose fields include private_key, endpoint_v4, endpoint_v6, endpoint_h2_v4, endpoint_h2_v6, endpoint_pub_key, license, id, access_token, ipv4 and ipv6. The README lists exactly those keys. After that, every client wants a different shape: Clash or Mihomo wants YAML, sing-box wants its own schema, Shadowrocket wants a share link, and a local VLESS bridge wants something else again.
The project compresses that into a page: register once, download usque-config.json, then re-import that file whenever you want to change Endpoint, Port, SNI, DNS or node count and regenerate. The stated audience is people meeting Usque or MASQUE for the first time, people who do not want to hand-edit YAML and JSON, and people who want to keep one native config around for repeat use. That last group is the one the design actually serves best, because the native file is treated as the single source rather than a throwaway output.
Registration flow: WebCrypto for the key, a Worker for the relay
The architecture is split so the private key never leaves the browser. In the Pages deployment, index.html, app.js and usque-register.js are served as static files, while /api/* is routed to _worker.js. A _routes.json file controls that split with include set to ["/api/*"] and an empty exclude array, so static pages do not pass through the API Worker. The Workers deployment does the same job through wrangler.jsonc, where an assets block points directory at ./public, binds ASSETS, and sets run_worker_first to ["/api/*"].
The sequence has three steps. The browser calls /api/warp/register, and the Worker forwards a fixed-format request to Cloudflare's WARP registration API. Then the browser generates the MASQUE key locally with WebCrypto using ECDSA over P-256, also called secp256r1, and converts it to the SEC1 DER Base64 form Usque expects. Finally the browser calls /api/warp/enroll, the Worker submits only the public key, and the response carries the MASQUE endpoint, the endpoint public key, interface IPv4 and IPv6, and device information. The browser combines that with the local private key to produce usque-config.json.
The practical consequence: the Worker is a relay, not a key holder. It sees a public key and returns server-side parameters. If you are evaluating this for a team, that is the design detail worth checking first, because it determines whether the hosted Pages URL is acceptable at all.
Deploying it to Cloudflare Pages and checking that the API is live
The README recommends Pages for a first deployment and describes a GitHub-connected flow. You push the repository, then in Cloudflare go to Workers & Pages, Create application, Pages, Connect to Git, and select the repo. The suggested settings are production branch main, framework preset None, root directory pages, build command left empty, and build output directory set to a single dot. The README adds a caveat worth repeating: console field names vary between Cloudflare versions, and what matters is that the publish root ends up containing index.html and _worker.js.
After deploying you get a pages.dev URL. The README's own smoke test is the health endpoint, which it shows as a path on your project domain:
https://你的项目.pages.dev/api/healthA working deployment returns this JSON, and the README says a healthy response confirms the static page, _worker.js, _routes.json and the API route are all in place:
{
"ok": true,
"service": "usque-register-relay",
"worker": "running"
}If you prefer not to connect a Git repository, the README also documents uploading the contents of the pages/ directory directly. In that case the publish root must still be the directory holding index.html and _worker.js. There is no npm install step documented for the Pages path, and the repository layout shows no dependency manifest under pages/, which fits a static-plus-Worker deployment.
Why 500 nodes is not 500 accounts
This is the part most likely to be misread. The generator offers 13, 32, 64 and 100 node presets plus a custom range from 1 to 500, and the README states plainly that this does not register 500 accounts. One set of Usque or WARP credentials is combined with different Endpoints and different Ports to produce many candidate connections, for example Endpoint A on 443, 500 and 4500, then Endpoint B on the same ports.
The README draws three negative conclusions from that: node count is not account count, node count is not distinct exit count, and node count does not multiply your traffic allowance. The bulk of candidates exists to be tested, so url-test can pick a working entry combination for your current network. The README also warns that a large node count does not mean every node works, because reachability of a given endpoint and port varies by network, region and carrier.
The second distinction is entry versus exit. Changing Endpoint, Port or SNI changes how you enter Cloudflare's network. The README is explicit that it does not force the final WARP exit IP into a particular country. What the project calls exit-country preference works the other way around: it probes the exits that already appear and selects nodes matching your preference. If your requirement is a guaranteed US or Japan exit, this tool does not claim to provide one.
Clash, Mihomo and the ChatGPT mode that keeps a config usable
The Clash and Mihomo output is the most opinionated piece. It generates MASQUE nodes, an automatic url-test group, a PROXY group, and a long list of per-service groups: AI, YouTube, Emby, TikTok, Netflix, Disney+, Spotify, GitHub, Telegram, Google, Twitter, X, Instagram, Facebook, Apple, Microsoft, Steam, Xbox, PlayStation, Nintendo, Bilibili, a general foreign-sites group, and a catch-all. Routing uses MetaCubeX MRS rule sets.
The default recommendation in this version is to send ChatGPT and OpenAI traffic DIRECT while other foreign traffic goes through WARP or MASQUE. The stated reason is failure containment: if a shared WARP exit is rejected by ChatGPT, a config that routes OpenAI through the proxy can break everything at once. The page lets you switch that group between DIRECT, an automatic AI selection, a region-preferred WARP node, a PROXY group, or a dedicated AI policy group.
That default is a judgement call, not a neutral one. Direct OpenAI traffic means your real address is visible to it. The README frames the choice as availability first. If your reason for using MASQUE is to avoid exposing your own address to a given service, you should override this default rather than accept it.
WARP exit detection and its Python dependency
The advanced feature, collapsed by default in the interface, drives a local Mihomo API to switch MASQUE nodes one at a time and record the actual exit IP, country, region and city, the Cloudflare PoP, latency, and HTTP reachability to ChatGPT. It can emit JSON or CSV reports and pick candidates by country preference. The repository layout shows a warp-egress-selector.py file in both the pages/ and workers/public/ directories.
Two constraints follow from that. First, this is a local operation: it needs a running Mihomo instance whose API it can reach, so it is not something the hosted page does for you. Second, because the helper is a Python file, the environment running it needs Python, and the README does not document the required version or any dependency list. The README also does not document what the selector does when the Mihomo API is unreachable or returns an error mid-run. If you plan to rely on the country report, that behaviour is the first thing to establish on your own machine.
Alternatives and the licence question
The closest alternative in practice is wgcf, which people also search for as wgcf-profile.conf. The difference is the output target. wgcf registers a WARP device and produces a WireGuard profile, which you then feed to a WireGuard client or convert yourself. Usque Custom Pro targets MASQUE instead of WireGuard, generates the client-side configs directly for Clash, sing-box, Shadowrocket and a VLESS bridge, and keeps a browser-held P-256 private key as part of the design. If your stack is already WireGuard and you want a single .conf file, wgcf is the shorter path. If you need MASQUE and multi-client output without hand-writing YAML, this project is aimed at you.
On licensing, no licence identifier is given. The repository listing shows .gitattributes, README.md, pages/ and workers/ at the top level, and no LICENSE file appears there. That is a real gap rather than a formality: without a licence, the default position is that no rights are granted, and the README's own upgrade instructions describe pulling new code from the repository. If you intend to deploy this inside an organisation rather than on a personal Cloudflare account, resolve the licence before you build anything on top of it. Nothing here is legal advice; the point is simply that the file is not there to read.
The maintenance picture is concrete rather than reassuring: the last push to the default branch was on 2026-09-09, and the repository is not archived. The README references v6.17 in its title while the introduction still says v6.7 in places, which suggests the document trails the code. Version drift in a README is cheap to fix and usually means the deployment section is the part most worth re-reading against your own Cloudflare console.
Editorial conclusion
Adopt Usque Custom Pro if you want a MASQUE device registered without hand-building a config, and you intend to keep the resulting config.json as your long-lived credential file. Skip it if you expect node count to buy you distinct exits or extra quota, or if you need a documented licence before shipping it inside a company. Before you commit, open the repository and confirm two things yourself: whether a LICENSE file exists, and whether the Pages or Workers path still matches your Cloudflare account's current field names, since the README warns the console labels shift between versions.
Frequently asked questions
Does Usque Custom Pro give me a US or Japan WARP exit?
No. The README states that changing Endpoint, Port or SNI changes how you enter Cloudflare's network and does not force the final WARP exit IP into a specific country. The exit-country feature detects the exits that already appear and selects nodes matching your preference.
If I generate 500 nodes in Usque Custom Pro, do I get 500 accounts or more traffic?
Neither. The README says the nodes come from one set of Usque or WARP credentials combined with different Endpoints and Ports, so node count is not account count, not distinct exit count, and does not multiply your traffic allowance.
What does Usque Custom Pro need before I can use the WARP exit detection?
The README describes the feature as driving a local Mihomo API to switch nodes and read exit IP, country, PoP and latency. The repository includes warp-egress-selector.py in both the pages/ and workers/public/ directories, so the machine running it needs Python, though the README does not document a required version.
Community notes