This article records the complete stepping process of configuring the WSTunnel client + Ficlash proxy on Termux once,The final root cause is that the IP address in the yaml file does not match the server side. The scripts encountered in the process cannot be generated, the domain name replacement error, and the process disappears are also sorted out, with screenshots and annotations for later reference.

1. Project background

Users refer to my tutorial https://www.shuijingwanwq.com/en/2026/06/02/15563/ Deploy on an Android phone:

• termux Run the WSTUnnel client
• Ficlash(Android graphics side of the Clash kernel) as a proxy client

I provided self-built VPN server information (domain name wg.shuijingwanwq.com, ip 154.21.196.249), the user copy the tutorial steps to the operation, but finallyMobile phone can’t access the Internet.

2. The serial pit of the script creation link

Screenshot 1 – User asks ‘Where can I find the domain name and IP’

Problem: Users do not have their own VPN, they use the trial service I provided, so the domain name and IP directly use the wg.shuijingwanwq.com And 154.21.196.249 can. However, the user does not understand this, which leads to a delay in replacement.

Solution: Inform users clearly, and directly copy the domain name and IP in the example in the trial scenario.

Screenshot 2 – ‘No such file or directory’ when giving permission

check in: The user command is indeed written as start-wstunnel.sh(there .sh), but the file does not exist.
root cause: user executes cat > ~/.termux/boot/start-wstunnel.sh << eof when, maybe due to the original text of my blog << erroneously escaped as <<(display the problem), causing the copied command to be Cat > ... << EOF error, filenot generated at all.

Lesson:<< It is the Heredoc syntax of the shell and must be entered as is. Later I have fixed the escape issue in the blog.

Screenshot 3 – ‘Your domain name’ is not replaced, causing wstunnel to report an error

When the user tries to manually enter the command,Fully keep the ‘your domain name’ and ‘your server ip’ placeholders in the tutorial, did not make any replacement, causing the wstunnel client to directly report the ‘invalid DNS name’ error.
At the same time, the command is incorrectly split into multiple lines, further destroying the syntax structure.

Lesson: Regardless of how the tutorial emphasizes, for first-time contact users, it is best to directly provide the complete command that can be copied (replace the placeholder with the real value and then send it to the user).

3. File generation and permission correction

After correcting, the user created the script with the correct command (replaced the real domain name and IP) (shot 4):

Subsequently the user executes chmod +x ~/.termux/boot/start-wstunnel time error,Lack of .sh Suffix.
I reminded in time in the chat:

Me:chmod +x ~/.termux/boot/start-wstunnel.sh
me: you are missing .sh

After the user correction,chmod The command was executed successfully.

4. The process disappears after a short start of wstunnel

user execution sh ~/.termux/boot/start-wstunnel.sh, the terminal prints the following logs (screenshot 5):

Remarks: The log display Info Starting WSTUnnel Client,UDP server listening,TLS handshake using SNI wg.shuijingwanwq.com, it seems that the connection is successful.

But the user executes ps -ef | grep wstunnel TimeCan’t see the process exists, confused.

real reason: Although the TLS handshake log is printed out, due to the client IP configured in the YAML file (10.7.0.3) and the IP actually allocated by the server (10.7.0.4) is inconsistent, causing the WireGuard virtual network card to fail to initialize the route correctly. Wstunnel client after attempting to establish a complete UDP channel due to the underlying configuration errorAutomatically crash and exit, which is not caused by the user pressing Ctrl+C.
Therefore,PS No resident WSTunnel process is seen.

5. Ficlash built-in WireGuard protocol

At this point the user started Ficlash and imported the YAML configuration file I sent.
(It should be noted that:Ficlash itself has built-in support for the WireGuard protocol, as one of the proxy node types, so users don’t need to install a standalone Wireguard application. )

But the dashboard is almost free of traffic (Screenshot 6):

Remarks: The uplink/downlink speed is extremely low, and the intranet IP is displayed as WIFI IP (192.168.1.34), and there is no proxy traffic.

The desktop of the mobile phone is shown in the figure (shot 7), only Termux, Ficlash, Termux Boot and other tools are installed.

The problem remains after restarting the phone.

6. Ultimate troubleshooting: IP address mismatch is the culprit

1. Use the same file to reproduce

Since the yaml fileI sent it directly to the user, I asked the user to send the whole set of files back to me, and use the same file to test directly on my own mobile phone,Sure enough, the exact same problem was reproduced– This proves that the problem is in the configuration file itself, not the user operating environment.

2. View the client.conf(screenshot 8)

Note: The key content—

[Interface]
Address = 10.7.0.4/24
DNS = 8.8.8.8, 8.8.4.4
...

The virtual IP assigned by the server to the client is 10.7.0.4.

3. Check the YAML file sent to the user

in yaml Proxies The WireGuard section below says:

ip: 10.7.0.3   # 错误！应为 10.7.0.4

This ip was mistakenly written by me when preparing the sample file, which is inconsistent with the IP actually allocated by the server.

WireGuard requires that the local virtual IP must be connected to the server side [Interface] The address is consistent (or at least belongs to the same subnet and unique), otherwise although the UDP tunnel may be established, the routing and packet forwarding will fail, and the traffic cannot be normally in and out. This is also the root cause of the wstunnel process crashing and exiting.

4. Modify to the correct IP instantaneous recovery (Screenshot 9)

Remarks: will IP: 10.7.0.3 To IP: 10.7.0.4, re-import yaml and connect, the dashboard immediately displays normal uplink/downlink traffic, and the mobile phone successfully accesses the external network.

7. Guide to summarizing and avoiding pits

root cause

• Direct reason: The WireGuard client IP in the YAML file is inconsistent with the server-side allocations (10.7.0.3 vs 10.7.0.4).
• indirect reason: The creation process of the startup script has been delayed due to blog escape character problems, placeholders have not been replaced, and the permission command is entered incorrectly, etc., and the troubleshooting time is delayed.
• Fuse: The example yaml file I sent has an error (write to death 10.7.0.3 and not synced with the actual server).

Lessons lessons

1. script creation: Always use the correct << hereDoc syntax, and check if the file is actually generated (using ls-l confirm). When posting the tutorial,Directly give the command to replace the real value, to prevent users from leaking placeholders.
2. process diagnosis:PS When you can’t see the process, don’t take it for granted that ‘the user exits the terminal’, it is likely that the configuration error caused the client to crash actively, and the system log should be checked (logcat Or dmesg) or runtime strace.
3. Configuration consistency: The IP, endpoint, and key of any VPN client must be exactly matched to the server side. Do not copy the example without checking.
4. Built-in protocol perception: Now clients such as Ficlash have built-in WireGuard support, no need to install independent applications, but this also means that the configured IP Fields must be extremely accurate.
5. When providing sample files: Be sure to use placeholders (such as your_client_ip) and individually labeled, orRun the complete process in person before sending it to users, to ensure that it is correct.

Attachment: The final correct startup script (for reference)

#!/data/data/com.termux/files/usr/bin/bash
termux-wake-lock
~/bin/wstunnel client -L udp://127.0.0.1:51820:127.0.0.1:51820?timeout_sec=0 --tls-sni-override wg.shuijingwanwq.com wss://154.21.196.249:443

(Note: Please replace the domain name and IP with your actual server information)

Postscript: It took nearly a day before and after the troubleshooting, and finally found that it was a small number error in the configuration file. It is hoped that this record can help you avoid detours. When encountering similar problems, you can start with the dual ‘consistency of configuration file’ and ‘process survival status’, which can often quickly locate. If you have any other questions, please leave a message to discuss.