[GH-ISSUE #2468] How to run the client as a service on windows 10? #1957

New issue

Closed

opened 2026-05-05 13:15:33 -06:00 by gitea-mirror · 14 comments

gitea-mirror commented 2026-05-05 13:15:33 -06:00

Owner

Copy link

Originally created by @smac89 on GitHub (Jul 2, 2021).
Original GitHub issue: https://github.com/fatedier/frp/issues/2468

The solution you want

I would like to run an frp client on windows 10, however I don't know how to keep programs running on windows. The windows package comes with systemd files, but I don't think systemd works on windows.

Alternatives considered

• Perhaps create a windows service? This works because it allows us to auto start the service at runtime.
• https://github.com/arkane-systems/genie

How to implement this function

• We just need configuration files which support any of the alternatives mentioned above

Application scenarios of this function

• Autostarting frpc/frps on windows platform

Originally created by @smac89 on GitHub (Jul 2, 2021). Original GitHub issue: https://github.com/fatedier/frp/issues/2468 <!-- From Chinese to English by machine translation, welcome to revise and polish. --> **The solution you want** <!--A clear and concise description of the solution you want. --> I would like to run an `frp` client on windows 10, however I don't know how to keep programs running on windows. The windows package comes with `systemd` files, but I don't think systemd works on windows. **Alternatives considered** <!--A clear and concise description of any alternative solutions or features you have considered. --> - Perhaps create a windows service? This works because it allows us to auto start the service at runtime. - https://github.com/arkane-systems/genie **How to implement this function** <!--Implementation steps for the solution you want. --> - We just need configuration files which support any of the alternatives mentioned above **Application scenarios of this function** <!--Make a clear and concise description of the application scenario of the solution you want. --> - Autostarting `frpc`/`frps` on windows platform

gitea-mirror 2026-05-05 13:15:33 -06:00

• closed this issue
• added the
  lifecycle/stale
  label

gitea-mirror commented 2026-05-05 13:15:37 -06:00

Author

Owner

Copy link

@fatedier commented on GitHub (Jul 8, 2021):

I'm not familier with windows service. I will try to study it in future when i have time.

<!-- gh-comment-id:876090463 --> @fatedier commented on GitHub (Jul 8, 2021): I'm not familier with windows service. I will try to study it in future when i have time.

gitea-mirror commented 2026-05-05 13:15:38 -06:00

Author

Owner

Copy link

@ghost commented on GitHub (Jul 8, 2021):

HI,

in this case you could remove the systemd folder in the windows zip files. Because systemd is not available on windows systems ;)

<!-- gh-comment-id:876133107 --> @ghost commented on GitHub (Jul 8, 2021): HI, in this case you could remove the systemd folder in the windows zip files. Because systemd is not available on windows systems ;)

gitea-mirror commented 2026-05-05 13:15:39 -06:00

Author

Owner

Copy link

@ghost commented on GitHub (Jul 8, 2021):

I figured it by doing the following steps:

1. Download https://github.com/winsw/winsw/releases/download/v2.11.0/WinSW-x64.exe
2. Create a file named "WinSW-x64.ini" with following content (replace the folder name)

<service>
  <id>frpc</id>
  <name>frpc</name>
  <description>It is a kind of magic</description>
  <executable>C:\Users\fancyuser\Desktop\frp\frpc.exe</executable>
  <arguments>-c C:\Users\fancyuser\Desktop\frp\frpc.ini</arguments>
  <log mode="roll"></log>
</service>

3. Run in a administrative powershell
   .\WinSW-x64.exe install .\WinSW-x64.xml

Now u have a service in services.msc u could start/stop and so on

@fatedier
A better way is you provide a .Net wrapper for your golang service we can add as a service (maybe something like https://github.com/judwhite/go-svc is required)

<!-- gh-comment-id:876153760 --> @ghost commented on GitHub (Jul 8, 2021): I figured it by doing the following steps: 1. Download https://github.com/winsw/winsw/releases/download/v2.11.0/WinSW-x64.exe 2. Create a file named "WinSW-x64.ini" with following content (replace the folder name) ``` <service> <id>frpc</id> <name>frpc</name> <description>It is a kind of magic</description> <executable>C:\Users\fancyuser\Desktop\frp\frpc.exe</executable> <arguments>-c C:\Users\fancyuser\Desktop\frp\frpc.ini</arguments> <log mode="roll"></log> </service> ``` 3. Run in a administrative powershell `.\WinSW-x64.exe install .\WinSW-x64.xml` Now u have a service in services.msc u could start/stop and so on @fatedier A better way is you provide a .Net wrapper for your golang service we can add as a service (maybe something like https://github.com/judwhite/go-svc is required)

gitea-mirror commented 2026-05-05 13:15:39 -06:00

Author

Owner

Copy link

@luangong commented on GitHub (Jul 9, 2021):

@smac89 I use NSSM (The Non-Sucking Service Manager) as a Windows service wrapper and it works very well. Just head over to https://nssm.cc/download, download the zip file, unzip it, and then run a command like this:

> C:\nssm-2.24\win64\nssm.exe install frpc

A dialog will show up where you can tweak all kinds of settings for the service. The only required fields are Path and Arguments. Enter the path to frpc.exe (e.g., C:\frp_0.37.0_amd64\frpc.exe) into the Path box and -c frpc.ini into the Arguments box. The Startup directory is optional, and defaults to the directory containing your frpc.exe (C:\frp_0.37.0_amd64) if you leave it blank.

You can optionally add a display name (e.g., "frp client") and a description for the frpc servic. When you are done, just hit the Edit service button and the frpc service will be up and running.

You can then double-check that the service is indeed running from within the task manager:

Finally, you can view/start/stop the service in Windows Services console (services.msc).

Note that the executable path is pointing to nssm.exe rather than frpc.exe because nssm.exe is the wrapper program and it will start frpc.exe as a child process.

<!-- gh-comment-id:877086583 --> @luangong commented on GitHub (Jul 9, 2021): @smac89 I use [NSSM (The Non-Sucking Service Manager)](https://nssm.cc/) as a Windows service wrapper and it works very well. Just head over to https://nssm.cc/download, download the zip file, unzip it, and then run a command like this: ``` > C:\nssm-2.24\win64\nssm.exe install frpc ``` A dialog will show up where you can tweak all kinds of settings for the service. The only required fields are **Path** and **Arguments**. Enter the path to `frpc.exe` (e.g., `C:\frp_0.37.0_amd64\frpc.exe`) into the **Path** box and `-c frpc.ini` into the **Arguments** box. The **Startup directory** is optional, and defaults to the directory containing your `frpc.exe` (`C:\frp_0.37.0_amd64`) if you leave it blank.  You can optionally add a display name (e.g., "frp client") and a description for the frpc servic. When you are done, just hit the **Edit service** button and the frpc service will be up and running.  You can then double-check that the service is indeed running from within the task manager:  Finally, you can view/start/stop the service in Windows Services console (`services.msc`).  Note that the executable path is pointing to `nssm.exe` rather than `frpc.exe` because `nssm.exe` is the wrapper program and it will start `frpc.exe` as a child process. 

gitea-mirror commented 2026-05-05 13:15:40 -06:00

Author

Owner

Copy link

@luangong commented on GitHub (Jul 9, 2021):

@fatedier I'm not familier with windows service. I will try to study it in future when i have time.

If we are releasing frp as a portable zip file containing two console programs and a bunch of other files I would suggest we keep the executables as simple as possible and let the other service wrappers (e.g., NSSM, WinSW, etc) do the dirty work.

On the other hand, if we are releasing frp as a Windows installer (.msi, etc) then I would suggest we provide native Windows service capability in frps.exe and frpc.exe, probably through a command-line argument such as -s/--service/-d/--daemon to tell them to run in "service/daemon" mode.

<!-- gh-comment-id:877093003 --> @luangong commented on GitHub (Jul 9, 2021): > @fatedier I'm not familier with windows service. I will try to study it in future when i have time. If we are releasing frp as a portable zip file containing two console programs and a bunch of other files I would suggest we keep the executables as simple as possible and let the other [service wrappers](https://en.wikipedia.org/wiki/Service_wrapper) (e.g., NSSM, WinSW, etc) do the dirty work. On the other hand, if we are releasing frp as a Windows installer (`.msi`, etc) then I would suggest we provide native Windows service capability in `frps.exe` and `frpc.exe`, probably through a command-line argument such as `-s`/`--service`/`-d`/`--daemon` to tell them to run in "service/daemon" mode.

gitea-mirror commented 2026-05-05 13:15:40 -06:00

Author

Owner

Copy link

@ghost commented on GitHub (Jul 9, 2021):

@fatedier I'm not familier with windows service. I will try to study it in future when i have time.

If we are releasing frp as a portable zip file containing two console programs and a bunch of other files I would suggest we keep the executables as simple as possible and let the other service wrappers (e.g., NSSM, WinSW, etc) do the dirty work.

On the other hand, if we are releasing frp as a Windows installer (.msi, etc) then I would suggest we provide native Windows service capability in frps.exe and frpc.exe, probably through a command-line argument such as -s / --service/-d/--daemon to tell them to run in "service/daemon" mode.

I'm with you by portable installations. But I didn't like the idea with -s/-d by full installations because:
It's not so complicated to code frp with as a real Windows Service and starting a programm in a deamon mode is not the same like a windows services.

I think it's also ok to place a text in the Readme how to use frp as a windows services like both solutions above, if you down like to have a bit more coding work to get a real windows service.
For me the best solution is:

If you have an installer like msi file the installer should ask "do you like to use frp as a service" if yes then implement a correct windows service - if not do nothing like that.

only my 2 cents :)

cheers

<!-- gh-comment-id:877141167 --> @ghost commented on GitHub (Jul 9, 2021): > > @fatedier I'm not familier with windows service. I will try to study it in future when i have time. > > If we are releasing frp as a portable zip file containing two console programs and a bunch of other files I would suggest we keep the executables as simple as possible and let the other [service wrappers](https://en.wikipedia.org/wiki/Service_wrapper) (e.g., NSSM, WinSW, etc) do the dirty work. > > On the other hand, if we are releasing frp as a Windows installer (`.msi`, etc) then I would suggest we provide native Windows service capability in `frps.exe` and `frpc.exe`, probably through a command-line argument such as `-s` / `--service`/`-d`/`--daemon` to tell them to run in "service/daemon" mode. I'm with you by portable installations. But I didn't like the idea with -s/-d by full installations because: It's not so complicated to code frp with as a real Windows Service and starting a programm in a deamon mode is not the same like a windows services. I think it's also ok to place a text in the Readme how to use frp as a windows services like both solutions above, if you down like to have a bit more coding work to get a real windows service. For me the best solution is: If you have an installer like msi file the installer should ask "do you like to use frp as a service" if yes then implement a correct windows service - if not do nothing like that. only my 2 cents :) cheers

gitea-mirror commented 2026-05-05 13:15:40 -06:00

Author

Owner

Copy link

@luangong commented on GitHub (Jul 9, 2021):

@sitzmoebelchronograph It's not so complicated to code frp with as a real Windows Service and starting a programm in a deamon mode is not the same like a windows services.

Agreed. Running in “daemon” mode is not enough. You have to actually “register” it as a service in Windows, and in Linux you also need a frpc.service file for systemd to be able to manage it. Linux programs (e.g., rsync) that can be run either as an interactive, one-off command or as a background service usually provide a command-line argument like -d/--daemon so that the .service file can be like this:

[Unit]
Description=fast remote file copy program daemon
Documentation=man:rsync(1) man:rsyncd.conf(5)
ConditionPathExists=/etc/rsyncd.conf
After=network.target

[Service]
ExecStart=/usr/bin/rsync --daemon --no-detach

[Install]
WantedBy=multi-user.target

Another example is a web proxy called Privoxy which provides two additional command-line options --install and --uninstall on Windows. If you run privoxy.exe --install, Privoxy will register itself as a Windows service and have Windows run it as privoxy.exe --service. You can check out their official documentation for more details.

So I’m still with the -d/--daemon flag 😄

References:

• Daemon (computing) — Wikipedia
• Windows service — Wikipedia
• daemonize — A tool to run a command as a daemon
• rsync(1) - Linux man page
• Register Privoxy as a service on Windows

<!-- gh-comment-id:877223715 --> @luangong commented on GitHub (Jul 9, 2021): > @sitzmoebelchronograph It's not so complicated to code frp with as a real Windows Service and starting a programm in a deamon mode is not the same like a windows services. Agreed. Running in “daemon” mode is not enough. You have to actually “register” it as a service in Windows, and in Linux you also need a `frpc.service` file for systemd to be able to manage it. Linux programs (e.g., [rsync](https://linux.die.net/man/1/rsync)) that can be run either as an interactive, one-off command or as a background service usually provide a command-line argument like `-d`/`--daemon` so that the `.service` file can be like this: <pre><code>[Unit] Description=fast remote file copy program daemon Documentation=man:rsync(1) man:rsyncd.conf(5) ConditionPathExists=/etc/rsyncd.conf After=network.target [Service] ExecStart=/usr/bin/rsync <strong>--daemon</strong> --no-detach [Install] WantedBy=multi-user.target</code></pre> Another example is a web proxy called Privoxy which provides two additional command-line options `--install` and `--uninstall` on Windows. If you run `privoxy.exe --install`, Privoxy will register itself as a Windows service and have Windows run it as `privoxy.exe --service`. You can check out their [official documentation](https://www.privoxy.org/user-manual/installation.html#INSTALLATION-PACK-WIN) for more details.  So I’m still with the `-d`/`--daemon` flag 😄 References: - [Daemon (computing) — Wikipedia](https://en.wikipedia.org/wiki/Daemon_(computing)) - [Windows service — Wikipedia](https://en.wikipedia.org/wiki/Windows_service) - [daemonize — A tool to run a command as a daemon](https://software.clapper.org/daemonize/) - [rsync(1) - Linux man page](https://linux.die.net/man/1/rsync) - [Register Privoxy as a service on Windows](https://www.privoxy.org/user-manual/installation.html#INSTALLATION-PACK-WIN)

gitea-mirror commented 2026-05-05 13:15:41 -06:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Aug 12, 2021):

Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.

<!-- gh-comment-id:897256535 --> @github-actions[bot] commented on GitHub (Aug 12, 2021): Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.

gitea-mirror commented 2026-05-05 13:15:41 -06:00

Author

Owner

Copy link

@smac89 commented on GitHub (Aug 14, 2021):

Hey guys, I just want to say thanks for all the suggestions.

Shortly after posting this, I discovered that Windows actually has a perfectly capable tool for doing something like this, already built in. It's unsurprisingly called Task Scheduler.

Let me just explain why I needed to use frp on Windows:

I have an accountant friend who works part-time for a local store, and wanted to use quickbooks remotely in case she wasn't able to drive to the store. I had recently purchased a VPS and setup RDP on my work computer (running linux), using frpc. So I was kinda curious if this will work on Windows as well.

The steps

Enable WSL and install Alpine Linux

• Enable WSL on Windows (there are tons of tutorials on how to do this)
• (As exciting as it may sound, don't upgrade to WSL2 because microsoft nerfed the host IP sharing in that version. See this post).
• Open windows store and download Alpine WSL, which is just alpine Linux packaged to work in WSL.
• (While you are in the store, might as well grab Windows Terminal. It's a much better experience than CMD)
• Open Alpine from the command line. (Just type in wsl and it should switch to Alpine)

Install frp in Alpine

• Install a text editor (nano works)
• Edit the file /etc/apk/repositories
• At the end of the file, add the following (you can change the urls if you want to a point to a server near you)

  @edge https://dl-cdn.alpinelinux.org/alpine/edge/main
  @edgecommunity https://dl-cdn.alpinelinux.org/alpine/edge/community
  

• Run the command apk update && apk add frp@edge
• This should hopefully be enough to install frp
• Create your frp[cs].ini (choose the correct one) file somewhere in the Documents folder (hide it so it doesn't get deleted by mistake)
• Setup all your configurations. Note that windows allows you to change the default rdp port, so use the correct one.

Windows task scheduler automation

I won't go into much details on how this one works, but pretty much every Windows machine comes with one. Just play with it and it won't take long to figure out. I find you can quickly setup complex tasks in less time than if you are trying to do the same with something like systemd or openrc.

• The command you need to start frp is as follows:

  wsl -d Alpine -u <username> -e frp[cs]
  

• Set the task to run at system startup and it should run in the same folder where you have stored your frp[cs].ini file.

End result

Oh and it is fast! Thanks guys!

<!-- gh-comment-id:898898294 --> @smac89 commented on GitHub (Aug 14, 2021): Hey guys, I just want to say thanks for all the suggestions. Shortly after posting this, I discovered that Windows actually has a perfectly capable tool for doing something like this, already built in. It's unsurprisingly called `Task Scheduler`. Let me just explain why I needed to use frp on Windows: I have an accountant friend who works part-time for a local store, and wanted to use quickbooks remotely in case she wasn't able to drive to the store. I had recently purchased a VPS and setup RDP on my work computer (running linux), using frpc. So I was kinda curious if this will work on Windows as well. ## The steps #### Enable WSL and install Alpine Linux - Enable WSL on Windows (there are tons of tutorials on how to do this) - (As exciting as it may sound, don't upgrade to WSL2 because microsoft nerfed the host IP sharing in that version. See this [post](https://docs.microsoft.com/en-us/windows/wsl/compare-versions)). - Open windows store and download `Alpine WSL`, which is just alpine Linux packaged to work in WSL. - (While you are in the store, might as well grab `Windows Terminal`. It's a much better experience than CMD) - Open Alpine from the command line. (Just type in `wsl` and it should switch to `Alpine`) #### Install frp in Alpine - Install a text editor (`nano` works) - Edit the file `/etc/apk/repositories` - At the end of the file, add the following (you can change the urls if you want to a point to a server near you) ``` @edge https://dl-cdn.alpinelinux.org/alpine/edge/main @edgecommunity https://dl-cdn.alpinelinux.org/alpine/edge/community ``` - Run the command `apk update && apk add frp@edge` - This should hopefully be enough to install `frp` - Create your `frp[cs].ini` (choose the correct one) file somewhere in the Documents folder (hide it so it doesn't get deleted by mistake) - Setup all your configurations. _Note that windows allows you to change the default `rdp` port, so use the correct one_. #### Windows task scheduler automation I won't go into much details on how this one works, but pretty much every Windows machine comes with one. Just play with it and it won't take long to figure out. I find you can quickly setup complex tasks in less time than if you are trying to do the same with something like `systemd` or `openrc`. - The command you need to start frp is as follows: ``` wsl -d Alpine -u <username> -e frp[cs] ``` - Set the task to run at system startup and it should run in the same folder where you have stored your `frp[cs].ini` file. End result  Oh and it is fast! Thanks guys!

gitea-mirror commented 2026-05-05 13:15:42 -06:00

Author

Owner

Copy link

@luangong commented on GitHub (Aug 14, 2021):

You can run TeamViewer / VNCViewer / Chrome Remote Desktop / AnyDesk Remote Desktop etc. on both computers so there is no need for a VPS or frp.

<!-- gh-comment-id:898916677 --> @luangong commented on GitHub (Aug 14, 2021): You can run TeamViewer / VNCViewer / Chrome Remote Desktop / AnyDesk Remote Desktop etc. on both computers so there is no need for a VPS or frp.

gitea-mirror commented 2026-05-05 13:15:42 -06:00

Author

Owner

Copy link

@smac89 commented on GitHub (Aug 14, 2021):

@luangong I didn't realize Chrome Remote Desktop can be be run as an RDP server. Good to know. I may have to try it out and see how fast it is.

The reason I went with frp is because both machines I am trying to obtain remote access to are not publicly available (no public IP/ports). The first one is my work computer running xrdp and it is hidden behind a private lan, and my friend's machine is more or less in the same boat.
Secondly, I wanted a virtual desktop session for both sessions, so VNC was out of the question which pretty much eliminates all those other options you listed.

I didn't blindly go into this and just picked frp for no reason. Chrome Remote Desktop did not immediately scream "RDP server" on initial inspection, so I never paid it more attention.
As I think about it, the setup offered by Chrome Remote Desktop is pretty much the same as what I have now with frp, because theirs also does not require a public IP, can run headless, and also come with systemd services. I guess we'll see how much faster their setup can be especially on Linux.

<!-- gh-comment-id:898953452 --> @smac89 commented on GitHub (Aug 14, 2021): @luangong I didn't realize Chrome Remote Desktop can be be run as an RDP server. Good to know. I may have to try it out and see how fast it is. The reason I went with `frp` is because both machines I am trying to obtain remote access to are not publicly available (no public IP/ports). The first one is my work computer running `xrdp` and it is hidden behind a private lan, and my friend's machine is more or less in the same boat. Secondly, I wanted a virtual desktop session for both sessions, so VNC was out of the question which pretty much eliminates all those other options you listed. I didn't blindly go into this and just picked `frp` for no reason. Chrome Remote Desktop did not immediately scream "RDP server" on initial inspection, so I never paid it more attention. As I think about it, the setup offered by Chrome Remote Desktop is pretty much the same as what I have now with `frp`, because theirs also does not require a public IP, can run headless, and also come with systemd services. I guess we'll see how much faster their setup can be especially on Linux.

gitea-mirror commented 2026-05-05 13:15:42 -06:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Sep 14, 2021):

Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.

<!-- gh-comment-id:918694775 --> @github-actions[bot] commented on GitHub (Sep 14, 2021): Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.

gitea-mirror commented 2026-05-05 13:15:43 -06:00

Author

Owner

Copy link

@kktt007 commented on GitHub (Mar 13, 2024):

@smac89 I use NSSM (The Non-Sucking Service Manager) as a Windows service wrapper and it works very well. Just head over to https://nssm.cc/download, download the zip file, unzip it, and then run a command like this:

> C:\nssm-2.24\win64\nssm.exe install frpc

A dialog will show up where you can tweak all kinds of settings for the service. The only required fields are Path and Arguments. Enter the path to frpc.exe (e.g., C:\frp_0.37.0_amd64\frpc.exe) into the Path box and -c frpc.ini into the Arguments box. The Startup directory is optional, and defaults to the directory containing your frpc.exe (C:\frp_0.37.0_amd64) if you leave it blank.

You can optionally add a display name (e.g., "frp client") and a description for the frpc servic. When you are done, just hit the Edit service button and the frpc service will be up and running.

You can then double-check that the service is indeed running from within the task manager:

Finally, you can view/start/stop the service in Windows Services console (services.msc).

Note that the executable path is pointing to nssm.exe rather than frpc.exe because nssm.exe is the wrapper program and it will start frpc.exe as a child process.

注册服务后nssm不能卸载咯，有什么其他方式吗，让他成为系统的服务，像很多其他软件比如360那样，禁都禁不掉的那种

<!-- gh-comment-id:1993407428 --> @kktt007 commented on GitHub (Mar 13, 2024): > @smac89 I use [NSSM (The Non-Sucking Service Manager)](https://nssm.cc/) as a Windows service wrapper and it works very well. Just head over to https://nssm.cc/download, download the zip file, unzip it, and then run a command like this: > > ``` > > C:\nssm-2.24\win64\nssm.exe install frpc > ``` > > A dialog will show up where you can tweak all kinds of settings for the service. The only required fields are **Path** and **Arguments**. Enter the path to `frpc.exe` (e.g., `C:\frp_0.37.0_amd64\frpc.exe`) into the **Path** box and `-c frpc.ini` into the **Arguments** box. The **Startup directory** is optional, and defaults to the directory containing your `frpc.exe` (`C:\frp_0.37.0_amd64`) if you leave it blank. > >  > > You can optionally add a display name (e.g., "frp client") and a description for the frpc servic. When you are done, just hit the **Edit service** button and the frpc service will be up and running. > >  > > You can then double-check that the service is indeed running from within the task manager: > >  > > Finally, you can view/start/stop the service in Windows Services console (`services.msc`). > >  > > Note that the executable path is pointing to `nssm.exe` rather than `frpc.exe` because `nssm.exe` is the wrapper program and it will start `frpc.exe` as a child process. > >  注册服务后nssm不能卸载咯，有什么其他方式吗，让他成为系统的服务，像很多其他软件比如360那样，禁都禁不掉的那种

gitea-mirror commented 2026-05-05 13:15:43 -06:00

Author

Owner

Copy link

@donmor commented on GitHub (Oct 5, 2025):

注册服务后nssm不能卸载咯，有什么其他方式吗，让他成为系统的服务，像很多其他软件比如360那样，禁都禁不掉的那种

我搞定了（是不是禁不掉另说）

<!-- gh-comment-id:3368864582 --> @donmor commented on GitHub (Oct 5, 2025): > 注册服务后nssm不能卸载咯，有什么其他方式吗，让他成为系统的服务，像很多其他软件比如360那样，禁都禁不掉的那种 我搞定了（是不是禁不掉另说）

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

dev

new

master

copilot/review-pull-request-5198

v0.68.1

v0.68.0

v0.67.0

v0.66.0

v0.65.0

v0.64.0

v0.63.0

v0.62.1

v0.62.0

v0.61.2

v0.61.1

v0.61.0

v0.60.0

v0.59.0

v0.58.1

v0.58.0

v0.57.0

v0.56.0

v0.55.1

v0.55.0

v0.54.0

v0.53.2

v0.53.1

v0.53.0

v0.52.3

v0.52.2

v0.52.1

v0.52.0

v0.51.3

v0.51.2

v0.51.1

v0.51.0

v0.50.0

v0.49.0

v0.48.0

v0.47.0

v0.46.1

v0.46.0

v0.45.0

v0.44.0

v0.43.0

v0.42.0

v0.41.0

v0.40.0

v0.39.1

v0.39.0

v0.38.0

v0.37.1

v0.37.0

v0.36.2

v0.36.1

v0.36.0

v0.35.1

v0.35.0

v0.34.3

v0.34.2

v0.34.1

v0.34.0

v0.33.0

v0.32.1

v0.32.0

v0.31.2

v0.31.1

v0.31.0

v0.30.0

v0.29.1

v0.29.0

v0.28.2

v0.28.1

v0.28.0

v0.27.1

v0.27.0

v0.26.0

v0.25.3

v0.25.2

v0.25.1

v0.25.0

v0.24.1

v0.24.0

v0.23.3

v0.23.2

v0.23.1

v0.23.0

v0.22.0

v0.21.0

v0.20.0

v0.19.1

v0.19.0

v0.18.0

v0.17.0

v0.16.1

v0.16.0

v0.15.1

v0.15.0

v0.14.1

v0.14.0

v0.13.0

v0.12.0

v0.11.0

v0.10.0

v0.9.3

v0.9.2

v0.9.1

v0.9.0

v0.8.1

v0.8.0

v0.7.0

v0.6.0

v0.5.0

v0.3.0

v0.2.0

v0.1.0

Labels

Clear labels   

In Progress

  

WIP

  

WaitingForInfo

  

bug

  

doc

  

duplicate

  

easy

  

enhancement

  

future

  

help wanted

  

invalid

  

lifecycle/stale

  

need-issue-template

  

need-usage-help

  

no plan

  

proposal

  

pull-request

Mirrored from GitHub Pull Request

  

question

  

todo

No labels

In Progress

WIP

WaitingForInfo

bug

doc

duplicate

easy

enhancement

future

help wanted

invalid

lifecycle/stale

need-issue-template

need-usage-help

no plan

proposal

pull-request

question

todo

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/frp#1957

No description provided.