github-starred/frp

Fork 0

mirror of https://github.com/fatedier/frp.git synced 2026-05-15 08:05:49 -06:00

[GH-ISSUE #2392] frpc连接失败的时候能否执行一个脚本？ #1902

New issue

Closed

opened 2026-05-05 13:13:36 -06:00 by gitea-mirror · 7 comments

gitea-mirror commented

2026-05-05 13:13:36 -06:00

Owner

Originally created by @GravenCh on GitHub (May 13, 2021).
Original GitHub issue: https://github.com/fatedier/frp/issues/2392

有时候远程连接到客户机，更新了frpc.ini之后发现出错了，但是已经不通了，所以无能为力

如果frpc能够在执行失败（配置文件错误、网络不通等所有情况下）时，执行一个bash，那就好了

Originally created by @GravenCh on GitHub (May 13, 2021). Original GitHub issue: https://github.com/fatedier/frp/issues/2392 有时候远程连接到客户机，更新了frpc.ini之后发现出错了，但是已经不通了，所以无能为力如果frpc能够在执行失败（配置文件错误、网络不通等所有情况下）时，执行一个bash，那就好了

gitea-mirror closed this issue

2026-05-05 13:13:37 -06:00

gitea-mirror commented

2026-05-05 13:13:39 -06:00

Author

Owner

@fatedier commented on GitHub (May 13, 2021):

能否举一个例子说明做了哪些类型的更新导致无法连通？

@fatedier commented on GitHub (May 13, 2021): 能否举一个例子说明做了哪些类型的更新导致无法连通？

gitea-mirror commented

2026-05-05 13:13:40 -06:00

Author

Owner

@GravenCh commented on GitHub (May 13, 2021):

能否举一个例子说明做了哪些类型的更新导致无法连通？

并非特指“哪些类型的更新”，比如刚才我连上了一台远程的客户机，希望新增一个TCP的穿透，然而我手误输错了且直接service restart，现在我的客户机就处于无法连通的状态。

如果能新增一个功能，使得frpc因为某种原因（比如配置文件格式错误等）无法正常启动和连接服务端时，能够调用一下指定的shell脚本，那就太好了

@GravenCh commented on GitHub (May 13, 2021): > 能否举一个例子说明做了哪些类型的更新导致无法连通？并非特指“哪些类型的更新”，比如刚才我连上了一台远程的客户机，希望新增一个TCP的穿透，然而我手误输错了且直接service restart，现在我的客户机就处于无法连通的状态。如果能新增一个功能，使得frpc因为某种原因（比如配置文件格式错误等）无法正常启动和连接服务端时，能够调用一下指定的shell脚本，那就太好了

gitea-mirror commented

2026-05-05 13:13:41 -06:00

Author

Owner

@ax2009live commented on GitHub (May 13, 2021):

这种一旦断开就 OVER 的场景，推荐的做法是：保持两个 frpc 工作，一个有问题，另外一个还可以连接；

@ax2009live commented on GitHub (May 13, 2021): 这种一旦断开就 OVER 的场景，推荐的做法是：保持两个 frpc 工作，一个有问题，另外一个还可以连接；

gitea-mirror commented

2026-05-05 13:13:42 -06:00

Author

Owner

@GravenCh commented on GitHub (May 13, 2021):

这种一旦断开就 OVER 的场景，推荐的做法是：保持两个 frpc 工作，一个有问题，另外一个还可以连接；

确实是准备这么做，但是如果客户端能支持无法连接时执行一个shell的话，那就有更多可定制的玩法了

@GravenCh commented on GitHub (May 13, 2021): > 这种一旦断开就 OVER 的场景，推荐的做法是：保持两个 frpc 工作，一个有问题，另外一个还可以连接；确实是准备这么做，但是如果客户端能支持无法连接时执行一个shell的话，那就有更多可定制的玩法了

gitea-mirror commented

2026-05-05 13:13:43 -06:00

Author

Owner

@ax2009live commented on GitHub (May 13, 2021):

frpc 都搞坏了，shell 意义何在？复杂化了，预防思维优于补救思维；

@ax2009live commented on GitHub (May 13, 2021): frpc 都搞坏了，shell 意义何在？复杂化了，预防思维优于补救思维；

gitea-mirror commented

2026-05-05 13:13:43 -06:00

Author

Owner

@fatedier commented on GitHub (May 14, 2021):

通常这样的设计需要考虑一个通用的可扩展性，如果只是为了解决某一个特定的问题，确实复杂化了。可以想想有没有其他的应对方式。

比如如果是增加 TCP 穿透，可以通过修改配置文件后 Reload 的方式来做，Reload 之前可以检查配置文件的有效性，出错的话就不会应用，也不会影响到正在运行的 frpc。

@fatedier commented on GitHub (May 14, 2021): 通常这样的设计需要考虑一个通用的可扩展性，如果只是为了解决某一个特定的问题，确实复杂化了。可以想想有没有其他的应对方式。比如如果是增加 TCP 穿透，可以通过修改配置文件后 Reload 的方式来做，Reload 之前可以检查配置文件的有效性，出错的话就不会应用，也不会影响到正在运行的 frpc。

gitea-mirror commented

2026-05-05 13:13:44 -06:00

Author

Owner

@GravenCh commented on GitHub (May 14, 2021):

通常这样的设计需要考虑一个通用的可扩展性，如果只是为了解决某一个特定的问题，确实复杂化了。可以想想有没有其他的应对方式。

比如如果是增加 TCP 穿透，可以通过修改配置文件后 Reload 的方式来做，Reload 之前可以检查配置文件的有效性，出错的话就不会应用，也不会影响到正在运行的 frpc。

好的，感谢🙏

@GravenCh commented on GitHub (May 14, 2021): > 通常这样的设计需要考虑一个通用的可扩展性，如果只是为了解决某一个特定的问题，确实复杂化了。可以想想有没有其他的应对方式。 > > 比如如果是增加 TCP 穿透，可以通过修改配置文件后 Reload 的方式来做，Reload 之前可以检查配置文件的有效性，出错的话就不会应用，也不会影响到正在运行的 frpc。好的，感谢🙏