Comprehensive Guide to Setting Up and Auto-Deploying VLESS Proxy Configurations
Step-by-step tutorial for forking, configuring security secrets, and running GitHub Actions
The zizifn project is a secure proxy configuration based on the VLESS-WS-TLS/TCP protocol. It is developed in Rust and WebAssembly (Wasm) architecture and runs on Cloudflare Workers using Wrangler. To deploy this project on your personal account, follow the step-by-step instructions below.
Error 1101 and 1102
In this new structure, there is no need to add useless code or heavy obfuscation!
📚 Table of Contents
Step 1: Forking the Repository
First, you need to create a copy of this project in your own GitHub account.
Go to the main repository page (Link)
Click on the Fork icon (marked with a red arrow) at the top of the page.
View Screenshot
- On the next page, you can optionally set a custom name for your fork. Otherwise, click on Create fork to transfer the project to your account.
View Screenshot
Step 2: Retrieving Cloudflare API Token and Account ID
For automated deployment, GitHub Actions needs to connect to your Cloudflare account. To do this, we need two key parameters:
- CloudFlare Account ID
- CloudFlare API Token
Note
Previously, to get the Account ID, you had to navigate to the Workers & Pages section and copy it from the bottom of the page. Now, when creating a token, the Account ID is displayed right there, so you can copy it directly from that screen.
Creating a Token with Worker Editing Permissions
- Log in to your Cloudflare dashboard.
Click to expand details
Note
Recently, Cloudflare does not allow account creation with disposable/temporary emails. The account might get created but won't get verified, and you might get stuck in an endless email verification loop. Therefore, it is highly recommended to use reliable email providers such as G-Mail, Outlook, Hotmail, ProtonMail, etc., to register your Cloudflare account.
- Once logged in, open the left sidebar/menu at the top of the page, type api in the Quick search box, and select Account API Tokens from the search results.
View Screenshot
- Click on the Create Token button.
View Screenshot
- From the API token templates, click on Edit Cloudflare Workers.
View Screenshot
- Under the Token Expiration section, set an expiration date for your token if needed, then proceed to view and create the token.
View Screenshot
Note
Please note that if the token expires, your deployed worker will NOT stop working. However, you will no longer be able to redeploy the project via GitHub Actions. If that happens, you must generate a new token and update the corresponding secret in your GitHub repository settings.
- Copy the generated API token on this page (this token is only shown once, so save it somewhere secure if needed). Also, copy your Account ID shown near the top of the page. After safely copying both values, click on the confirmation button to close the window.
View Screenshot
Step 3: Setting up GitHub Secrets
Now, you need to add the retrieved credentials to your forked GitHub repository so the workflow can authenticate with your Cloudflare account.
- In your forked repository, go to the Settings tab.
View Screenshot
- From the sidebar menu, click on Secrets and variables and select Actions.
View Screenshot
- Click on the New repository secret button and define the variables according to the table below:
| Secret Name | Status | Default Value | Description |
|---|---|---|---|
CLOUDFLARE_API_TOKEN | ✔️ Required | - | Your Cloudflare API token with Workers editing permissions. |
CLOUDFLARE_ACCOUNT_ID | ✔️ Required | - | Your Cloudflare Account ID. |
UUID | ⚙️ Optional | be0ff9df-1468-41a0-8865-796d1c6800db | Your custom UUID (v4). |
PROXYIP | ⚙️ Optional | di.nscl.ir | Proxy IP to route traffic to backend services behind Cloudflare. |
View Screenshot
Important Note
The first two variables (Cloudflare Account ID and API Token) are strictly required. Without them, you cannot deploy the worker. The other two variables (UUID and PROXYIP) are optional because the code falls back to pre-defined values. However, it is highly recommended to generate a unique UUID using (this website) and use it instead of the default value.
Step 4: Activating and Running GitHub Actions
By default, GitHub disables actions on forked repositories. You need to enable and run the workflow manually once.
Navigate to the Actions tab at the top of your repository.
Click on the green button:
"I understand my workflows, go ahead and enable them"
to authorize the actions to run.
View Screenshot
- As shown in the screenshot below, select All workflows from the left panel, then choose the Deploy Worker workflow.
View Screenshot
On the right side of the screen, a menu bar with a Run workflow button will appear. Click on it.
In the dropdown form that opens, you can optionally input custom values for
Proxy IPorUUIDexclusively for this specific run. (If left blank, the workflow will fallback to your repository secrets or default values; it is generally recommended to set them up as secrets instead).
View Screenshot
- Finally, click the green Run workflow button inside the form. After about 30 to 60 seconds, a green checkmark will appear next to the run, indicating that the deployment process completed successfully.
View Screenshot
Important Note on Temporary Variables
Values entered directly into the Run workflow prompt form are strictly temporary (one-time use) and are not stored in your repository configuration. This feature is particularly useful for quickly testing different Proxy IPs or changing the UUID on the fly.
Technical Details
After clicking Run workflow, GitHub boots up an Ubuntu runner, downloads and installs the Rust toolchain (cargo) and wasm-pack, compiles the Rust codebase to WebAssembly, and automatically deploys a new Worker named zr-wasm to your Cloudflare account.
If you wish to change the default worker name, you can edit the first line of the wrangler.toml file inside your repository.
View Screenshot
How to Use
Accessing the Management Panel
Once deployed, simply append your UUID to your Worker's URL:
https://Your-Worker-URL/Your-UUID
For example:
https://zr-wasm.workers.dev/be0ff9df-1468-41a0-8865-796d1c6800db
If you did not create a custom UUID secret and are using the default code value, the UUID will be:
regbe0ff9df-1468-41a0-8865-796d1c6800db
Retrieving the Subscription Link
Your subscription link automatically serves multiple configurations populated with clean Cloudflare IPs. You can use the buttons inside the panel to copy it automatically.
Alternatively, if you need the subscription URL manually for external clients, append xray or sb between the Worker URL and your UUID:
https://Your-Worker-URL/xray/Your-UUID
https://Your-Worker-URL/sb/Your-UUID
For example:
https://zr-wasm.workers.dev/xray/be0ff9df-1468-41a0-8865-796d1c6800db
Differences Between xray and sb
- xray suffix:
Suitable for clients utilizing the Xray core, such as:
v2rayNG, MahsaNG, Hiddify, Nekoray, v2rayN, Streisand, Napsternet, NPVT, Happ, etc.
- sb suffix:
Suitable for clients utilizing the Sing-Box core, such as:
Nekobox, Exclave, Singbox, Husi, Karing, etc.
- Clean Cloudflare IPs
The clean IPs in your configurations are sourced from the NiREvil/vless repository. The IPs are updated automatically every 4 hours.
INFO
Security Warning
Click to view important security tips
Never hardcode or type sensitive Cloudflare tokens in manual workflow run forms!
Values typed directly into the manual workflow execution inputs are saved in your GitHub Actions run history. If your repository is public, these credentials will be visible to everyone. Sensitive secrets must always be defined via Step 3 (Repository Secrets) so GitHub can securely encrypt them.