Compare commits
625 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
c4440b58e3 | ||
|
|
7caf103fe6 | ||
|
|
e55bb89247 | ||
|
|
8c3acb1dc5 | ||
|
|
f416efbe64 | ||
|
|
95e6f4ceab | ||
|
|
9d3a54058e | ||
|
|
69b94f65c7 | ||
|
|
8ec4062626 | ||
|
|
2baa6514ef | ||
|
|
8fcc72fc88 | ||
|
|
3324d51819 | ||
|
|
0f47eebbfb | ||
|
|
bb1b0e9902 | ||
|
|
449e861518 | ||
|
|
37336917ac | ||
|
|
3a6e6db9cc | ||
|
|
43fd5ea174 | ||
|
|
ea87ce6faa | ||
|
|
62d10de2e9 | ||
|
|
27d9cceeec | ||
|
|
f1e76c2569 | ||
|
|
1ee5d658ae | ||
|
|
a784bc1ddd | ||
|
|
303e4a3322 | ||
|
|
4a2464dd7d | ||
|
|
f52596525d | ||
|
|
c9bfba6905 | ||
|
|
6de614b83f | ||
|
|
b997f57ad8 | ||
|
|
267799b356 | ||
|
|
fb0d6d3e5e | ||
|
|
f5a01fc41c | ||
|
|
62abff91eb | ||
|
|
2d78544388 | ||
|
|
bc053dfa40 | ||
|
|
01bbe1f0d2 | ||
|
|
28b4519d17 | ||
|
|
3667783857 | ||
|
|
742fb99c48 | ||
|
|
82335bd882 | ||
|
|
41a32049ee | ||
|
|
ef696a7dd4 | ||
|
|
7c9693276f | ||
|
|
577b4116a1 | ||
|
|
0748cd419a | ||
|
|
7b893170f2 | ||
|
|
7cb5321db1 | ||
|
|
9e8447f5b9 | ||
|
|
c809f31257 | ||
|
|
a31008b009 | ||
|
|
de52793774 | ||
|
|
af14e4f61a | ||
|
|
8c13e647e5 | ||
|
|
b73871e1d0 | ||
|
|
fc5e5663dc | ||
|
|
dd66e75a8b | ||
|
|
3e8fee303d | ||
|
|
60852fa6d7 | ||
|
|
a3fe7cc90c | ||
|
|
cf095dfb70 | ||
|
|
a96002949c | ||
|
|
29757b8dd7 | ||
|
|
d83d061623 | ||
|
|
1ce4068029 | ||
|
|
b288e1098b | ||
|
|
e885803422 | ||
|
|
07e508c16a | ||
|
|
a829daa344 | ||
|
|
75635acbe3 | ||
|
|
89ac706d57 | ||
|
|
3ec0163130 | ||
|
|
b4656f3b44 | ||
|
|
1be4e3f84a | ||
|
|
f9ae7d5b16 | ||
|
|
041f1cc18c | ||
|
|
ca8aabe98c | ||
|
|
1a10952fdd | ||
|
|
ecacaa9d76 | ||
|
|
72912848be | ||
|
|
bb9c53fe8f | ||
|
|
c369495c1d | ||
|
|
85403b0247 | ||
|
|
c653de4305 | ||
|
|
5e19c4c310 | ||
|
|
e0dcb4691f | ||
|
|
f997328be3 | ||
|
|
f0ad4910be | ||
|
|
14ec78086a | ||
|
|
6d4d2a407b | ||
|
|
e47bf4fb77 | ||
|
|
64edb7f964 | ||
|
|
8601a68272 | ||
|
|
c7b2b6bc9d | ||
|
|
0d1cc22e90 | ||
|
|
6a8f4e7125 | ||
|
|
7c4e7ee630 | ||
|
|
e8434b55d6 | ||
|
|
e0adb83e10 | ||
|
|
2107cbe1d0 | ||
|
|
05025175c1 | ||
|
|
f1ba1c8852 | ||
|
|
1895670ccf | ||
|
|
f09cb15774 | ||
|
|
c5c77f23a5 | ||
|
|
afedb3fc73 | ||
|
|
9f56367840 | ||
|
|
4a9ba739c2 | ||
|
|
853dd3bfba | ||
|
|
eb55e77ace | ||
|
|
2ed201e01d | ||
|
|
bba742454f | ||
|
|
73925574f2 | ||
|
|
7c819f1916 | ||
|
|
862409419e | ||
|
|
be3265490a | ||
|
|
1141c91462 | ||
|
|
cbb74248c2 | ||
|
|
d5ed465bf2 | ||
|
|
47dacf6c02 | ||
|
|
025746fec6 | ||
|
|
40d733f849 | ||
|
|
427604651f | ||
|
|
6d4dcf934a | ||
|
|
ad3b2972fa | ||
|
|
35fbb5df50 | ||
|
|
ef57dcb31b | ||
|
|
b86bf1130e | ||
|
|
60d68c60df | ||
|
|
b229602ef3 | ||
|
|
d90ebbff74 | ||
|
|
b7a0e9d00e | ||
|
|
cfda4e557a | ||
|
|
8f8c016036 | ||
|
|
d64193cb14 | ||
|
|
d4c92385dc | ||
|
|
71e65f94ff | ||
|
|
5987c982c1 | ||
|
|
54c97ceec5 | ||
|
|
66bb70538c | ||
|
|
c99a06e4c7 | ||
|
|
5a1fccb222 | ||
|
|
657d6d1a29 | ||
|
|
855fc29ecc | ||
|
|
a728194488 | ||
|
|
cf6edc6674 | ||
|
|
6ac988fc3e | ||
|
|
75e71b5d6b | ||
|
|
34c57edca0 | ||
|
|
cf0a44c1a8 | ||
|
|
779cef4b28 | ||
|
|
55e3b7a13b | ||
|
|
13acfff6c0 | ||
|
|
c22bd801fe | ||
|
|
fef5aaef86 | ||
|
|
991bbf1e12 | ||
|
|
b1d1e256c6 | ||
|
|
bba7a56927 | ||
|
|
3b53f4cbaf | ||
|
|
61e5ce4acd | ||
|
|
89192e90e6 | ||
|
|
54519896ec | ||
|
|
86892aea95 | ||
|
|
6778e19799 | ||
|
|
06222cba38 | ||
|
|
e41ab2429b | ||
|
|
ca74e758bb | ||
|
|
978cc810ce | ||
|
|
47cbdee34b | ||
|
|
1f6a86db9d | ||
|
|
9d879e883d | ||
|
|
6dadba6504 | ||
|
|
0f319dc853 | ||
|
|
789c9a40df | ||
|
|
86be03268a | ||
|
|
8c8fcc20a6 | ||
|
|
efa2e85af4 | ||
|
|
85e141848c | ||
|
|
76195ce056 | ||
|
|
23556682a8 | ||
|
|
c7e895862f | ||
|
|
def1660756 | ||
|
|
3c45c90676 | ||
|
|
68613058cb | ||
|
|
8679919b65 | ||
|
|
054abdb96b | ||
|
|
c9257c44dd | ||
|
|
dc11d18587 | ||
|
|
5a9b48a2e2 | ||
|
|
f4bde46e05 | ||
|
|
7129bb05df | ||
|
|
220324d9db | ||
|
|
08c3f20cba | ||
|
|
375f223360 | ||
|
|
a0c75fa70b | ||
|
|
5231b344ea | ||
|
|
a3e94cb891 | ||
|
|
0f21319ed1 | ||
|
|
0a576a85b5 | ||
|
|
57ea5f90fc | ||
|
|
60f4098a45 | ||
|
|
692fa45a45 | ||
|
|
3035bcf103 | ||
|
|
c9cc8e0b77 | ||
|
|
8af8de77dc | ||
|
|
8c2f68a774 | ||
|
|
8176fc8e36 | ||
|
|
6df4fd8379 | ||
|
|
1a9dc1ef60 | ||
|
|
4613a2f4be | ||
|
|
c65e46d9c3 | ||
|
|
d926057828 | ||
|
|
d84492a64b | ||
|
|
121e221d08 | ||
|
|
b828c17c39 | ||
|
|
54803cb085 | ||
|
|
e4dbb9d795 | ||
|
|
6d85db0061 | ||
|
|
7530c31538 | ||
|
|
85bfedfdab | ||
|
|
06b0688202 | ||
|
|
e270689c58 | ||
|
|
c0e18591ba | ||
|
|
ed4f98403a | ||
|
|
db793f2050 | ||
|
|
d349be4f3b | ||
|
|
917092db54 | ||
|
|
6b4b5993d3 | ||
|
|
1d1e5870ae | ||
|
|
86766a0b53 | ||
|
|
b05235b2a6 | ||
|
|
dbc74d3158 | ||
|
|
f2fe08d88c | ||
|
|
f08d263fbf | ||
|
|
fdf1b55f0b | ||
|
|
49298e55fc | ||
|
|
a19dd62de9 | ||
|
|
3b5a298f3f | ||
|
|
7e69986764 | ||
|
|
f2e9cd22b6 | ||
|
|
024bdff112 | ||
|
|
6dc7e29780 | ||
|
|
ff2560f548 | ||
|
|
7df3533bc4 | ||
|
|
d7d5c89f6c | ||
|
|
f510e2d2d6 | ||
|
|
71ff715cb2 | ||
|
|
f32cd13a03 | ||
|
|
231e0bf346 | ||
|
|
d3d7f346aa | ||
|
|
5d65f9ce63 | ||
|
|
a669d77d6d | ||
|
|
dadf095e29 | ||
|
|
3ae7a0f11b | ||
|
|
2419d02a39 | ||
|
|
6f954bdbb5 | ||
|
|
58fb335d7c | ||
|
|
f21154f447 | ||
|
|
a0a0382c90 | ||
|
|
d418fe3873 | ||
|
|
674c67f946 | ||
|
|
f477a7ea7b | ||
|
|
d168ad4789 | ||
|
|
d93dfa553b | ||
|
|
418b8883a0 | ||
|
|
b85e018b36 | ||
|
|
95836210df | ||
|
|
7a9867cf59 | ||
|
|
1b34691f73 | ||
|
|
078348917a | ||
|
|
43a5ddc239 | ||
|
|
2942a2ce71 | ||
|
|
ee739c01ff | ||
|
|
720d3a977a | ||
|
|
0cbfe645b6 | ||
|
|
e0f0874254 | ||
|
|
a1902bf170 | ||
|
|
6ac3c8ac2b | ||
|
|
5087511713 | ||
|
|
19e0d1bbc0 | ||
|
|
81ee0368af | ||
|
|
98124d7026 | ||
|
|
386095d84f | ||
|
|
61fe3b8a7f | ||
|
|
b2f6d10299 | ||
|
|
2f2b070975 | ||
|
|
259f0e7852 | ||
|
|
f0f8ead2d4 | ||
|
|
443f672d3f | ||
|
|
a6982dc315 | ||
|
|
8fea2a844f | ||
|
|
a17050b442 | ||
|
|
55bf044c0d | ||
|
|
6bdadc7078 | ||
|
|
aaa5f9221d | ||
|
|
65cf5ee334 | ||
|
|
893a5c8fda | ||
|
|
6fbdda369d | ||
|
|
1ecf0bb78a | ||
|
|
4a8868b3a0 | ||
|
|
2dcfe5dae4 | ||
|
|
6114fcbe4b | ||
|
|
892ad1df19 | ||
|
|
474d8d8b5e | ||
|
|
21cd4794fa | ||
|
|
1366e5e027 | ||
|
|
147c60d8f9 | ||
|
|
b62332709f | ||
|
|
0389477d7c | ||
|
|
dd30978be8 | ||
|
|
efed69f57f | ||
|
|
227f66a04b | ||
|
|
26cd2385b5 | ||
|
|
dcfe734c04 | ||
|
|
1832396336 | ||
|
|
acefd04413 | ||
|
|
6b6f521472 | ||
|
|
10921d466c | ||
|
|
f918ed3222 | ||
|
|
75d78a2c29 | ||
|
|
04b704023e | ||
|
|
e658be3f3e | ||
|
|
506eb9bc98 | ||
|
|
cfc7ca64b2 | ||
|
|
e910df0c26 | ||
|
|
a4b20c5345 | ||
|
|
d084d36dcc | ||
|
|
0c2c34b6ec | ||
|
|
25ec149689 | ||
|
|
40e2f7266c | ||
|
|
ef8e23aa37 | ||
|
|
75257f9c65 | ||
|
|
b35b093c2b | ||
|
|
baa9749e03 | ||
|
|
42733d2c6f | ||
|
|
19418d3ab7 | ||
|
|
a5b03da0b6 | ||
|
|
51856771cb | ||
|
|
2748c95e34 | ||
|
|
a62f24fd8a | ||
|
|
a38b7972dc | ||
|
|
5b3ceb5979 | ||
|
|
c7f75258e0 | ||
|
|
5050e48de3 | ||
|
|
1debea4fef | ||
|
|
2ca5f97eb6 | ||
|
|
a4d6992d34 | ||
|
|
3e9a2a2268 | ||
|
|
7bc82299cd | ||
|
|
543a3344b7 | ||
|
|
1a245ceb4b | ||
|
|
855f8eef69 | ||
|
|
91f60c1242 | ||
|
|
dc1779b054 | ||
|
|
625f5318cb | ||
|
|
63af979058 | ||
|
|
6fb833ed11 | ||
|
|
1464a54a41 | ||
|
|
23f1aea77f | ||
|
|
7f0ca75f21 | ||
|
|
f4f9f8cb35 | ||
|
|
0116b98f7b | ||
|
|
249a261a47 | ||
|
|
41053277e8 | ||
|
|
863e6d4d2a | ||
|
|
201ba300f5 | ||
|
|
825bac9a4a | ||
|
|
880a976d6f | ||
|
|
e78b288809 | ||
|
|
54fab1a4ce | ||
|
|
ae4ec0e40c | ||
|
|
5c13aa1942 | ||
|
|
e6662b4e12 | ||
|
|
73cf7078cf | ||
|
|
4db1b07a54 | ||
|
|
1382d5fa0b | ||
|
|
16fb136c0b | ||
|
|
d2d0773dbf | ||
|
|
0ca9b35ac0 | ||
|
|
c07a441c86 | ||
|
|
07de9070f6 | ||
|
|
f6441a3a2c | ||
|
|
0e4cfea09b | ||
|
|
fc5d8e9e14 | ||
|
|
123e915eb5 | ||
|
|
beea564f99 | ||
|
|
79a96992fd | ||
|
|
bf3a2b10a5 | ||
|
|
a32243fea4 | ||
|
|
4e79f9a2c0 | ||
|
|
43ad05c802 | ||
|
|
a8263c8f99 | ||
|
|
6d321d476d | ||
|
|
2b48660c1a | ||
|
|
8efd5fdee7 | ||
|
|
0b482db51f | ||
|
|
7ca970b60f | ||
|
|
233a585366 | ||
|
|
885a2e273e | ||
|
|
392752b7c8 | ||
|
|
bbd4da1ccd | ||
|
|
c8918231c1 | ||
|
|
870a8166d4 | ||
|
|
864964600a | ||
|
|
df67bb828e | ||
|
|
010323ccbc | ||
|
|
6d5740636b | ||
|
|
8c5d4e95cd | ||
|
|
d96a6c3679 | ||
|
|
ba3df3ed93 | ||
|
|
e821f562bd | ||
|
|
8de6c45fd7 | ||
|
|
0314568609 | ||
|
|
2769926d1c | ||
|
|
c8e7cc8b54 | ||
|
|
7cd2a1cea3 | ||
|
|
ae78b44d00 | ||
|
|
f847e91687 | ||
|
|
243bc6e519 | ||
|
|
40b9458aa3 | ||
|
|
460cc7a97e | ||
|
|
a95285f712 | ||
|
|
56e1a9158a | ||
|
|
1889f2d452 | ||
|
|
b20c8bdcf4 | ||
|
|
7da0215bcf | ||
|
|
686df8fb44 | ||
|
|
65f8a2cd5e | ||
|
|
c3ed786722 | ||
|
|
e65f7e2606 | ||
|
|
d5b56e31c6 | ||
|
|
92bbabb6ed | ||
|
|
c749a41e7b | ||
|
|
a55d782de4 | ||
|
|
cc01cf01b8 | ||
|
|
697f380f75 | ||
|
|
fd9f79c8d2 | ||
|
|
7f2568601a | ||
|
|
8e5505eb20 | ||
|
|
96e16d5ef4 | ||
|
|
26293316a5 | ||
|
|
c09deef5b9 | ||
|
|
598a489fa5 | ||
|
|
31f3840a4d | ||
|
|
fa3108276e | ||
|
|
60ceb2ee13 | ||
|
|
b743480594 | ||
|
|
b55a59dc84 | ||
|
|
b66838c9b8 | ||
|
|
2849f85c40 | ||
|
|
c50b7199bb | ||
|
|
bbac4c9a32 | ||
|
|
ab527b8d3e | ||
|
|
25d73bc4eb | ||
|
|
8a10b10b05 | ||
|
|
c84126ded5 | ||
|
|
cb3ee718ec | ||
|
|
dc299573cf | ||
|
|
e6168f8dcf | ||
|
|
2c3b453d9b | ||
|
|
4475ec1c98 | ||
|
|
4b63fde3e4 | ||
|
|
a984022e3e | ||
|
|
9434da4498 | ||
|
|
7e9296d027 | ||
|
|
8107b7f2ec | ||
|
|
3845a15adf | ||
|
|
9e0278c11a | ||
|
|
1b22d60f18 | ||
|
|
2e37028cc6 | ||
|
|
2fbda555d4 | ||
|
|
87134615df | ||
|
|
ca293753a6 | ||
|
|
a9144b43d6 | ||
|
|
8f4b035e6b | ||
|
|
f3cbb485a2 | ||
|
|
fd799e6b2f | ||
|
|
a6b0188a11 | ||
|
|
6cc571e078 | ||
|
|
69043cedb2 | ||
|
|
f56b3fb035 | ||
|
|
363ad67c2b | ||
|
|
e7ce4dc94c | ||
|
|
94b86a500b | ||
|
|
b0101d814a | ||
|
|
1ac633b14d | ||
|
|
c158ab96ba | ||
|
|
283d2feb77 | ||
|
|
ffeb12bb8e | ||
|
|
5487b0dbca | ||
|
|
12dfea650b | ||
|
|
7e9e2b1be7 | ||
|
|
5aab4b5c96 | ||
|
|
3ecd86af16 | ||
|
|
3c2ccd8559 | ||
|
|
8f1938fb03 | ||
|
|
64605200e7 | ||
|
|
7e33b5eb92 | ||
|
|
1636c8733a | ||
|
|
e735dc261d | ||
|
|
6266530044 | ||
|
|
7b4226b22a | ||
|
|
69e8a60623 | ||
|
|
b7ab1947a3 | ||
|
|
bb0a8cc122 | ||
|
|
aa0a5002c6 | ||
|
|
3c5e4e408b | ||
|
|
8215b68004 | ||
|
|
320950b868 | ||
|
|
d2618ca7a4 | ||
|
|
386952b821 | ||
|
|
d53a84d108 | ||
|
|
20a5ba078c | ||
|
|
aaa8872c21 | ||
|
|
269db8016c | ||
|
|
e164a174da | ||
|
|
9ceaf33652 | ||
|
|
573cdb5848 | ||
|
|
38a2b4f0e0 | ||
|
|
a0d0b83cc3 | ||
|
|
bcc0db7c9f | ||
|
|
45f8db9856 | ||
|
|
3c559ac588 | ||
|
|
5bc234ae17 | ||
|
|
72598b6124 | ||
|
|
5e7a4ea36c | ||
|
|
769d2ca90b | ||
|
|
a53d1c573f | ||
|
|
0d775fa86e | ||
|
|
e28de8f858 | ||
|
|
21ce1f6788 | ||
|
|
0f04e54679 | ||
|
|
4f04d4db8e | ||
|
|
9d74d4efeb | ||
|
|
bd4528bdeb | ||
|
|
e49f54cb77 | ||
|
|
cfb836f387 | ||
|
|
a56b71b0a5 | ||
|
|
64b0b14f52 | ||
|
|
5879c0e20c | ||
|
|
415a6b9c09 | ||
|
|
f0124c0412 | ||
|
|
8247cc0b53 | ||
|
|
192223472a | ||
|
|
dcceb5f69e | ||
|
|
e4cff51d8e | ||
|
|
4a6df92897 | ||
|
|
60a597d731 | ||
|
|
a9269f965b | ||
|
|
f7d24fcebe | ||
|
|
05e3dec374 | ||
|
|
cce7ddfde8 | ||
|
|
2938cbe3c9 | ||
|
|
e67926eda3 | ||
|
|
1a8f142e44 | ||
|
|
272b2da97e | ||
|
|
595c26a9ab | ||
|
|
f17abd31af | ||
|
|
beddbf5b3e | ||
|
|
fe67cf8550 | ||
|
|
072af7f162 | ||
|
|
0579dabbe6 | ||
|
|
e99a7d51a1 | ||
|
|
c4b447048f | ||
|
|
425e50f816 | ||
|
|
11e560bfbe | ||
|
|
da07b69dec | ||
|
|
1c3c7b9f07 | ||
|
|
3fea4147c2 | ||
|
|
06ee5cb681 | ||
|
|
06d790ce33 | ||
|
|
f9799b40e4 | ||
|
|
63390c2851 | ||
|
|
11b033456d | ||
|
|
fa1c2f4d13 | ||
|
|
84e052c40f | ||
|
|
3c849b774d | ||
|
|
2936a1f428 | ||
|
|
63c3ef9cb1 | ||
|
|
6b5be2e3c0 | ||
|
|
7c2e4ac792 | ||
|
|
0f80367491 | ||
|
|
d5d536d7e4 | ||
|
|
dd2666f642 | ||
|
|
e8615aed4f | ||
|
|
d0550350f4 | ||
|
|
70fba1dd81 | ||
|
|
86446bf6b8 | ||
|
|
b21e8d391d | ||
|
|
6e65d88ff2 | ||
|
|
d9a04a7791 | ||
|
|
a9f5d8901e | ||
|
|
0c0a3a6717 | ||
|
|
1ef96311eb | ||
|
|
f780238221 | ||
|
|
a763027166 | ||
|
|
8897681115 | ||
|
|
6739d8e69d | ||
|
|
c6eaa6e4e7 | ||
|
|
416b3ff51b | ||
|
|
f25b5c5d1b | ||
|
|
0b0c7130e4 | ||
|
|
89594238e9 | ||
|
|
a88d62402c | ||
|
|
f2c679918f | ||
|
|
8cdb46b2e8 | ||
|
|
3c2689e416 | ||
|
|
947db90578 | ||
|
|
4e518b4023 | ||
|
|
a0074635d4 | ||
|
|
4afcf3cc63 | ||
|
|
724546626e | ||
|
|
35cbd72e51 | ||
|
|
8167451715 | ||
|
|
1dcc079808 | ||
|
|
1fa6163971 | ||
|
|
8b0ec030e5 | ||
|
|
d53b9159ff | ||
|
|
7dca81129c | ||
|
|
14d93a05c0 | ||
|
|
ebe3edfd9c | ||
|
|
35eb862f60 | ||
|
|
1443811434 | ||
|
|
9cfbfa004f | ||
|
|
eabeff84a5 |
15
.github/FUNDING.yml
vendored
Normal file
@@ -0,0 +1,15 @@
|
||||
# These are supported funding model platforms
|
||||
|
||||
github: # Replace with up to 4 GitHub Sponsors-enabled usernames e.g., [user1, user2]
|
||||
patreon: # Replace with a single Patreon username
|
||||
open_collective: # Replace with a single Open Collective username
|
||||
ko_fi: # Replace with a single Ko-fi username
|
||||
tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
|
||||
community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
|
||||
liberapay: # Replace with a single Liberapay username
|
||||
issuehunt: # Replace with a single IssueHunt username
|
||||
lfx_crowdfunding: # Replace with a single LFX Crowdfunding project-name e.g., cloud-foundry
|
||||
polar: # Replace with a single Polar username
|
||||
buy_me_a_coffee: # Replace with a single Buy Me a Coffee username
|
||||
thanks_dev: # Replace with a single thanks.dev username
|
||||
custom: ['https://docs.rw/donate']
|
||||
106
.github/workflows/build-docs.yml
vendored
Normal file
@@ -0,0 +1,106 @@
|
||||
name: Build docs and landing
|
||||
|
||||
on:
|
||||
push:
|
||||
branches:
|
||||
- main
|
||||
workflow_dispatch:
|
||||
|
||||
jobs:
|
||||
build-landing:
|
||||
name: Build landing
|
||||
runs-on: ubuntu-22.04
|
||||
steps:
|
||||
- name: Checkout landing repository
|
||||
uses: actions/checkout@v4
|
||||
with:
|
||||
repository: remnawave/landing
|
||||
token: ${{ secrets.LANDING_REPO_TOKEN }}
|
||||
|
||||
- name: Setup Node
|
||||
uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: '22.18.0'
|
||||
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
|
||||
- name: Build landing
|
||||
run: npm run start:build
|
||||
|
||||
- name: Upload landing artifact
|
||||
uses: actions/upload-artifact@v4
|
||||
with:
|
||||
name: landing-build
|
||||
path: landing/
|
||||
|
||||
build-docs:
|
||||
name: Build documentation
|
||||
runs-on: ubuntu-22.04
|
||||
steps:
|
||||
- name: Checkout docs repository
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Setup Node
|
||||
uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: '22.18.0'
|
||||
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
|
||||
- name: Build documentation
|
||||
run: npm run build
|
||||
|
||||
- name: Upload docs artifact
|
||||
uses: actions/upload-artifact@v4
|
||||
with:
|
||||
name: docs-build
|
||||
path: build/
|
||||
|
||||
build-docker:
|
||||
name: Build and push Docker image
|
||||
runs-on: ubuntu-22.04
|
||||
needs: [build-landing, build-docs]
|
||||
steps:
|
||||
- name: Checkout docs repository
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Download landing artifact
|
||||
uses: actions/download-artifact@v4
|
||||
with:
|
||||
name: landing-build
|
||||
path: landing/
|
||||
|
||||
- name: Download docs artifact
|
||||
uses: actions/download-artifact@v4
|
||||
with:
|
||||
name: docs-build
|
||||
path: build/
|
||||
|
||||
- name: Set up Docker Buildx
|
||||
uses: docker/setup-buildx-action@v3
|
||||
|
||||
- name: Login to Docker Hub
|
||||
uses: docker/login-action@v3
|
||||
with:
|
||||
username: ${{ secrets.DOCKERHUB_USERNAME }}
|
||||
password: ${{ secrets.DOCKERHUB_TOKEN }}
|
||||
|
||||
- name: Build and push Docker image
|
||||
uses: docker/build-push-action@v5
|
||||
with:
|
||||
context: .
|
||||
push: true
|
||||
tags: |
|
||||
remnawave/internal-docs:latest
|
||||
platforms: linux/amd64
|
||||
|
||||
- name: Deploy to Railway
|
||||
run: |
|
||||
curl -fsSL https://railway.app/install.sh | sh
|
||||
export PATH=$PATH:$HOME/.railway/bin
|
||||
railway redeploy --service ${{ env.SVC_ID }} -y
|
||||
env:
|
||||
RAILWAY_TOKEN: ${{ secrets.RAILWAY_TOKEN }}
|
||||
SVC_ID: ${{ secrets.RAILWAY_SERVICE_ID }}
|
||||
164
.gitignore
vendored
Normal file
@@ -0,0 +1,164 @@
|
||||
# Logs
|
||||
logs
|
||||
*.log
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
lerna-debug.log*
|
||||
.pnpm-debug.log*
|
||||
|
||||
# Diagnostic reports (https://nodejs.org/api/report.html)
|
||||
report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json
|
||||
|
||||
# Runtime data
|
||||
pids
|
||||
*.pid
|
||||
*.seed
|
||||
*.pid.lock
|
||||
|
||||
# Directory for instrumented libs generated by jscoverage/JSCover
|
||||
lib-cov
|
||||
|
||||
# Coverage directory used by tools like istanbul
|
||||
coverage
|
||||
*.lcov
|
||||
|
||||
# nyc test coverage
|
||||
.nyc_output
|
||||
|
||||
# Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files)
|
||||
.grunt
|
||||
|
||||
# Bower dependency directory (https://bower.io/)
|
||||
bower_components
|
||||
|
||||
# node-waf configuration
|
||||
.lock-wscript
|
||||
|
||||
# Compiled binary addons (https://nodejs.org/api/addons.html)
|
||||
build/Release
|
||||
|
||||
# Dependency directories
|
||||
node_modules/
|
||||
jspm_packages/
|
||||
|
||||
# Snowpack dependency directory (https://snowpack.dev/)
|
||||
web_modules/
|
||||
|
||||
# TypeScript cache
|
||||
*.tsbuildinfo
|
||||
|
||||
# Optional npm cache directory
|
||||
.npm
|
||||
|
||||
# Optional eslint cache
|
||||
.eslintcache
|
||||
|
||||
# Optional stylelint cache
|
||||
.stylelintcache
|
||||
|
||||
# Microbundle cache
|
||||
.rpt2_cache/
|
||||
.rts2_cache_cjs/
|
||||
.rts2_cache_es/
|
||||
.rts2_cache_umd/
|
||||
|
||||
# Optional REPL history
|
||||
.node_repl_history
|
||||
|
||||
# Output of 'npm pack'
|
||||
*.tgz
|
||||
|
||||
# Yarn Integrity file
|
||||
.yarn-integrity
|
||||
.yarn.lock
|
||||
|
||||
# dotenv environment variable files
|
||||
.env
|
||||
.env.development.local
|
||||
.env.test.local
|
||||
.env.production.local
|
||||
.env.local
|
||||
|
||||
# parcel-bundler cache (https://parceljs.org/)
|
||||
.cache
|
||||
.parcel-cache
|
||||
|
||||
# Next.js build output
|
||||
.next
|
||||
out
|
||||
|
||||
# Nuxt.js build / generate output
|
||||
.nuxt
|
||||
dist
|
||||
|
||||
# Gatsby files
|
||||
.cache/
|
||||
# Comment in the public line in if your project uses Gatsby and not Next.js
|
||||
# https://nextjs.org/blog/next-9-1#public-directory-support
|
||||
# public
|
||||
|
||||
# vuepress build output
|
||||
.vuepress/dist
|
||||
|
||||
# vuepress v2.x temp and cache directory
|
||||
.temp
|
||||
.cache
|
||||
|
||||
# Docusaurus cache and generated files
|
||||
.docusaurus
|
||||
|
||||
# Serverless directories
|
||||
.serverless/
|
||||
|
||||
# FuseBox cache
|
||||
.fusebox/
|
||||
|
||||
# DynamoDB Local files
|
||||
.dynamodb/
|
||||
|
||||
# TernJS port file
|
||||
.tern-port
|
||||
|
||||
# Stores VSCode versions used for testing VSCode extensions
|
||||
.vscode-test
|
||||
|
||||
# yarn v2
|
||||
.yarn/cache
|
||||
.yarn/unplugged
|
||||
.yarn/build-state.yml
|
||||
.yarn/install-state.gz
|
||||
.pnp.*
|
||||
|
||||
.DS_Store
|
||||
.vercel
|
||||
stats.html
|
||||
fsd-high-level-dependencies.html
|
||||
|
||||
|
||||
# Dependencies
|
||||
/node_modules
|
||||
|
||||
# Production
|
||||
/build
|
||||
|
||||
# Generated files
|
||||
.docusaurus
|
||||
.cache-loader
|
||||
|
||||
# Misc
|
||||
.DS_Store
|
||||
.env.local
|
||||
.env.development.local
|
||||
.env.test.local
|
||||
.env.production.local
|
||||
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
|
||||
|
||||
.wip/
|
||||
|
||||
samples/
|
||||
docker-compose.local.yml
|
||||
8
.prettierrc
Normal file
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"singleQuote": true,
|
||||
"singleAttributePerLine": false,
|
||||
"tabWidth": 4,
|
||||
"printWidth": 100,
|
||||
"semi": false,
|
||||
"trailingComma": "none"
|
||||
}
|
||||
5
.vscode/settings.json
vendored
Normal file
@@ -0,0 +1,5 @@
|
||||
{
|
||||
"i18n-ally.localesPaths": [
|
||||
"static/contributing/i18n"
|
||||
]
|
||||
}
|
||||
76
Caddyfile
Normal file
@@ -0,0 +1,76 @@
|
||||
# global options
|
||||
{
|
||||
admin off
|
||||
persist_config off
|
||||
auto_https off
|
||||
# log {
|
||||
# format json
|
||||
# }
|
||||
servers {
|
||||
trusted_proxies static private_ranges 100.0.0.0/8
|
||||
}
|
||||
}
|
||||
|
||||
:{$PORT:8080} {
|
||||
handle /health {
|
||||
respond "OK" 200
|
||||
}
|
||||
|
||||
@notMainDomain {
|
||||
not header Host docs.rw
|
||||
}
|
||||
handle @notMainDomain {
|
||||
redir https://docs.rw{uri} permanent
|
||||
}
|
||||
|
||||
@mainDomain {
|
||||
header Host docs.rw
|
||||
}
|
||||
|
||||
handle @mainDomain {
|
||||
redir /blog/learn /docs/learn/quick-start permanent
|
||||
redir /blog/learn/quick-start /docs/learn/quick-start permanent
|
||||
redir /apps /docs/clients permanent
|
||||
redir /clients /docs/clients permanent
|
||||
redir /donate /docs/donate permanent
|
||||
|
||||
handle / {
|
||||
root * /app/landing
|
||||
encode gzip
|
||||
file_server
|
||||
try_files {path} /index.html
|
||||
|
||||
header {
|
||||
X-Content-Type-Options "nosniff"
|
||||
X-Frame-Options "DENY"
|
||||
X-XSS-Protection "1; mode=block"
|
||||
}
|
||||
}
|
||||
|
||||
handle_path /landing-assets/* {
|
||||
root * /app/landing/landing-assets
|
||||
encode gzip
|
||||
file_server
|
||||
try_files {path} /index.html
|
||||
|
||||
header {
|
||||
X-Content-Type-Options "nosniff"
|
||||
X-Frame-Options "DENY"
|
||||
X-XSS-Protection "1; mode=block"
|
||||
}
|
||||
}
|
||||
|
||||
handle {
|
||||
root * /app/docs
|
||||
encode gzip
|
||||
file_server
|
||||
try_files {path} /index.html
|
||||
|
||||
header {
|
||||
X-Content-Type-Options "nosniff"
|
||||
X-Frame-Options "DENY"
|
||||
X-XSS-Protection "1; mode=block"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
17
Dockerfile
Normal file
@@ -0,0 +1,17 @@
|
||||
ARG CADDY_VERSION=2.10
|
||||
ARG IMAGE_NAME=remnawave-docs
|
||||
|
||||
FROM caddy:${CADDY_VERSION}-alpine
|
||||
|
||||
LABEL name=${IMAGE_NAME}
|
||||
|
||||
WORKDIR /app
|
||||
|
||||
COPY build /app/docs
|
||||
COPY landing /app/landing
|
||||
|
||||
COPY Caddyfile /etc/caddy/Caddyfile
|
||||
|
||||
EXPOSE ${PORT:-80}
|
||||
|
||||
CMD ["caddy", "run", "--config", "/etc/caddy/Caddyfile", "--adapter", "caddyfile"]
|
||||
37
README.md
@@ -1 +1,36 @@
|
||||
WIP
|
||||
<div align="center">
|
||||
<a href="https://docs.rw">
|
||||
<img src="https://cdn.docs.rw/logos/logo.svg" alt="Logo" width="160" height="160">
|
||||
</a>
|
||||
|
||||
<h1 align="center">Remnawave</h3>
|
||||
|
||||
<p align="center">
|
||||
A powerful proxy management tool, built on top of Xray-core, with a focus on simplicity and ease of use.
|
||||
<br />
|
||||
<p align="center">
|
||||
<a href="https://docs.rw">
|
||||
<img src="https://img.shields.io/badge/Get%20Started-%E2%86%92-0969da?style=for-the-badge&labelColor=0969da&color=0969da" alt="Get Started" width="200" height="auto">
|
||||
</a>
|
||||
</p>
|
||||
<a href="https://github.com/remnawave/panel/releases">
|
||||
<img src="https://img.shields.io/github/v/release/remnawave/panel?label=Latest%20release&style=social" alt="Latest release">
|
||||
</a>
|
||||
<a href="https://github.com/remnawave/panel/stargazers">
|
||||
<img src="https://img.shields.io/github/stars/remnawave?style=social" alt="Stars">
|
||||
</a>
|
||||
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<p align="center">
|
||||
<a href="https://github.com/remnawave/panel" target="_blank" rel="noopener noreferrer" >
|
||||
<img src="https://cdn.docs.rw/logos/gh_preview.png" alt="Remnawave screenshots" width="600" height="auto">
|
||||
</a>
|
||||
</p>
|
||||
|
||||
<p align="center">
|
||||
<a href="https://t.me/remnawave" target="_blank" rel="noopener noreferrer">
|
||||
<img src="https://img.shields.io/badge/Join%20community-Telegram-26A5E4?style=for-the-badge&logo=telegram&logoColor=white" alt="Join community on Telegram" width="220" height="auto">
|
||||
</a>
|
||||
</p>
|
||||
|
||||
115
_panel-docs/help-articles/en/AUTH_METHODS_GENERIC.md
Normal file
@@ -0,0 +1,115 @@
|
||||
# Generic OAuth2 Authentication
|
||||
|
||||
Generic OAuth2 allows you to connect any OAuth2-compatible identity provider to Remnawave. This is useful when you want to use providers that don't have dedicated integration (like Authentik, Authelia, Zitadel, Google, Microsoft, etc.).
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. An OAuth2-compatible identity provider
|
||||
2. Admin access to create OAuth2 clients/applications
|
||||
3. Provider must support the `email` claim in tokens
|
||||
|
||||
## Configuration Steps
|
||||
|
||||
### 1. Create an OAuth2 Application in Your Provider
|
||||
|
||||
The exact steps vary by provider, but generally you need to:
|
||||
|
||||
1. Log in to your identity provider's admin console
|
||||
2. Create a new OAuth2/OIDC application
|
||||
3. Configure:
|
||||
- **Application Type**: Web Application
|
||||
- **Grant Type**: Authorization Code
|
||||
- **Redirect URI**: `https://your-panel-domain.com/oauth2/callback/generic`
|
||||
4. Note down the **Client ID** and **Client Secret**
|
||||
5. Find the provider's **Authorization URL** and **Token URL** (usually in documentation or well-known endpoint)
|
||||
|
||||
### 2. Find Provider URLs
|
||||
|
||||
Most providers have these endpoints documented. Common patterns:
|
||||
|
||||
| Provider | Authorization URL | Token URL |
|
||||
| --------- | ------------------------------------------------------------------ | -------------------------------------------------------------- |
|
||||
| Google | `https://accounts.google.com/o/oauth2/v2/auth` | `https://oauth2.googleapis.com/token` |
|
||||
| Microsoft | `https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize` | `https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token` |
|
||||
| Authentik | `https://your-authentik.com/application/o/authorize/` | `https://your-authentik.com/application/o/token/` |
|
||||
| Authelia | `https://your-authelia.com/api/oidc/authorization` | `https://your-authelia.com/api/oidc/token` |
|
||||
| Zitadel | `https://your-zitadel.com/oauth/v2/authorize` | `https://your-zitadel.com/oauth/v2/token` |
|
||||
|
||||
### 3. PKCE Support
|
||||
|
||||
**PKCE (Proof Key for Code Exchange)** adds an extra layer of security to the OAuth2 flow. Enable this option if:
|
||||
|
||||
- Your provider supports PKCE (most modern providers do)
|
||||
- You want enhanced security against authorization code interception attacks
|
||||
- Your provider requires PKCE for public clients
|
||||
|
||||
> **Recommendation**: Enable PKCE if your provider supports it.
|
||||
|
||||
## Remnawave Configuration
|
||||
|
||||
| Field | Description |
|
||||
| --------------------- | ------------------------------------------------------------------------------------- |
|
||||
| **Client ID** | The client/application ID from your OAuth2 provider |
|
||||
| **Client Secret** | The client secret from your OAuth2 provider |
|
||||
| **Authorization URL** | The OAuth2 authorization endpoint URL (e.g., `https://provider.com/oauth2/authorize`) |
|
||||
| **Token URL** | The OAuth2 token endpoint URL (e.g., `https://provider.com/oauth2/token`) |
|
||||
| **Frontend Domain** | Your Remnawave panel domain without `https://` (e.g., `panel.example.com`) |
|
||||
| **With PKCE** | Enable PKCE (Proof Key for Code Exchange) for enhanced security |
|
||||
| **Allowed Emails** | List of email addresses allowed to log in |
|
||||
|
||||
## Access Control
|
||||
|
||||
You can control access using **one of two methods** (or both):
|
||||
|
||||
### Option A: Using Allowed Emails
|
||||
|
||||
Specify a list of allowed email addresses in the Remnawave settings. Only users with emails in this list will be able to log in.
|
||||
|
||||
### Option B: Using Custom Claim
|
||||
|
||||
If the **Allowed Emails** list is empty, Remnawave will check for a custom claim in the token:
|
||||
|
||||
| Key | Value |
|
||||
| ----------------- | ------ |
|
||||
| `remnawaveAccess` | `true` |
|
||||
|
||||
If the user's token contains `remnawaveAccess: true`, they will be authorized.
|
||||
|
||||
> **Note**: You need to configure your identity provider to include this custom claim in the token. The exact steps vary by provider — usually this is done via "mappers", "claims", or "token customization" settings.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### "Invalid redirect URI"
|
||||
|
||||
Verify that the redirect URI in your provider matches exactly: `https://your-panel-domain.com/oauth2/callback/generic`
|
||||
|
||||
### "Invalid or missing email claim"
|
||||
|
||||
Make sure:
|
||||
|
||||
- The user has an email address set in your provider
|
||||
- The `email` scope is requested and granted
|
||||
- Your provider includes the `email` claim in the token
|
||||
|
||||
### "State mismatch"
|
||||
|
||||
Clear browser cookies and try again. This can happen if the authentication flow was interrupted.
|
||||
|
||||
### "Token exchange failed"
|
||||
|
||||
Verify that:
|
||||
|
||||
- The **Token URL** is correct
|
||||
- **Client ID** and **Client Secret** are correct
|
||||
- Your provider's token endpoint is accessible from your Remnawave server
|
||||
|
||||
### "Access denied"
|
||||
|
||||
The user's email is not in the **Allowed Emails** list. Add their email address to grant access.
|
||||
|
||||
### PKCE-related errors
|
||||
|
||||
If you get errors related to `code_verifier` or `code_challenge`:
|
||||
|
||||
- Try disabling **With PKCE** if your provider doesn't support it
|
||||
- Or enable it if your provider requires it
|
||||
19
_panel-docs/help-articles/en/AUTH_METHODS_GITHUB.md
Normal file
@@ -0,0 +1,19 @@
|
||||
## OAuth2: GitHub
|
||||
|
||||
### Creating an OAuth Application
|
||||
|
||||
First, you need to create an OAuth application.
|
||||
Follow the link to create an application: [https://github.com/settings/applications/new](https://github.com/settings/applications/new)
|
||||
|
||||
In the `Authorization callback URL` field, enter the address of your panel.
|
||||
|
||||
```bash
|
||||
# Replace YOUR_PANEL_DOMAIN with your panel address
|
||||
https://YOUR_PANEL_DOMAIN/oauth2/callback/github
|
||||
```
|
||||
|
||||
Don't forget to replace `YOUR_PANEL_DOMAIN` with the correct panel address.
|
||||
|
||||
### OAuth2 Settings in Remnawave
|
||||
|
||||
After creating the OAuth2 application – copy the `Client ID` and `Client Secret`. Insert this data in the corresponding section. And below, enter the list of email addresses for which login will be allowed.
|
||||
80
_panel-docs/help-articles/en/AUTH_METHODS_KEYCLOAK.md
Normal file
@@ -0,0 +1,80 @@
|
||||
# Keycloak Authentication
|
||||
|
||||
Keycloak is an open-source Identity and Access Management solution that provides Single Sign-On (SSO) capabilities.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. A running Keycloak server
|
||||
2. Admin access to create clients
|
||||
|
||||
## Configuration Steps
|
||||
|
||||
### 1. Create a Client in Keycloak
|
||||
|
||||
1. Log in to Keycloak Admin Console
|
||||
2. Select your realm (or create a new one)
|
||||
3. Go to **Clients** → **Create client**
|
||||
4. Configure:
|
||||
- **Client ID**: `remnawave` (or your preferred name)
|
||||
- **Client Protocol**: `openid-connect`
|
||||
- **Client authentication**: `ON`
|
||||
5. Set **Valid redirect URIs**: `https://your-panel-domain.com/oauth2/callback/keycloak`
|
||||
6. Set **Web Origins**: `https://your-panel-domain.com`
|
||||
7. Save the client
|
||||
|
||||
### 2. Get Client Credentials
|
||||
|
||||
1. Go to **Clients** → your client → **Credentials** tab
|
||||
2. Copy the **Client secret**
|
||||
|
||||
### 3. Configure Access Control
|
||||
|
||||
You can control access using **one of two methods** (or both):
|
||||
|
||||
#### Option A: Using Claim (Recommended)
|
||||
|
||||
Add a custom claim `remnawaveAccess: true` to the token:
|
||||
|
||||
1. Go to **Clients** → your client → **Client scopes** tab
|
||||
2. Click on `<your-client-id>-dedicated`
|
||||
3. Go to **Mappers** tab → **Add mapper** → **By configuration**
|
||||
4. Select **Hardcoded claim**
|
||||
5. Configure:
|
||||
- **Name**: `remnawaveAccess`
|
||||
- **Token Claim Name**: `remnawaveAccess`
|
||||
- **Claim value**: `true`
|
||||
- **Claim JSON Type**: `boolean`
|
||||
- **Add to ID token**: `ON`
|
||||
- **Add to access token**: `ON`
|
||||
6. Save
|
||||
|
||||
#### Option B: Using Allowed Emails
|
||||
|
||||
Instead of configuring a claim, you can specify a list of allowed email addresses in the Remnawave settings. Only users with emails in this list will be able to log in.
|
||||
|
||||
## Remnawave Configuration
|
||||
|
||||
| Field | Description |
|
||||
|-------|-------------|
|
||||
| **Keycloak Domain** | Your Keycloak server domain without `https://` (e.g., `keycloak.example.com`) |
|
||||
| **Frontend Domain** | Your Remnawave panel domain without `https://` (e.g., `panel.example.com`) |
|
||||
| **Realm** | The Keycloak realm name (e.g., `master`) |
|
||||
| **Client ID** | The client ID you created |
|
||||
| **Client Secret** | The client secret from Credentials tab |
|
||||
| **Allowed Emails** | List of email addresses allowed to log in (optional if using claim) |
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### "Email is not in the allowed list and remnawaveAccess claim is not present"
|
||||
Make sure either:
|
||||
- The user has the `remnawaveAccess: true` claim configured via mapper, OR
|
||||
- The user's email is added to the Allowed Emails list in Remnawave settings
|
||||
|
||||
### "Invalid redirect URI"
|
||||
Verify that the redirect URI in Keycloak matches exactly: `https://your-panel-domain.com/oauth2/callback/keycloak`
|
||||
|
||||
### "State mismatch"
|
||||
Clear browser cookies and try again. This can happen if the authentication flow was interrupted.
|
||||
|
||||
### "Invalid or missing email claim"
|
||||
Make sure the user has an email address set in Keycloak and email scope is enabled.
|
||||
21
_panel-docs/help-articles/en/AUTH_METHODS_PASSWORD.md
Normal file
@@ -0,0 +1,21 @@
|
||||
## Authentication Method: Password
|
||||
|
||||
### Changing or Resetting Password
|
||||
|
||||
Use `Rescue CLI` to reset or change the password.
|
||||
|
||||
```bash
|
||||
docker exec -it remnawave remnawave
|
||||
```
|
||||
|
||||
After entering `Rescue CLI`, select the `Reset superadmin` option.
|
||||
|
||||
### Emergency Password Authentication Enable
|
||||
|
||||
If you have disabled the "Password" authentication method but later lost access to one of the other authentication methods – you can enable the "Password" authentication method using `Rescue CLI`
|
||||
|
||||
```bash
|
||||
docker exec -it remnawave remnawave
|
||||
```
|
||||
|
||||
After entering `Rescue CLI`, select the `Enable password authentication` option.
|
||||
36
_panel-docs/help-articles/en/AUTH_METHODS_POCKETID.md
Normal file
@@ -0,0 +1,36 @@
|
||||
## OAuth2: PocketID
|
||||
|
||||
### Creating an OIDC Client
|
||||
|
||||
Log in to the PocketID admin panel and navigate to the `Settings` → `OIDC Clients` → `Add OIDC Client` section.
|
||||
|
||||
```
|
||||
# Replace YOUR_PANEL_DOMAIN with your Remnawave panel address
|
||||
https://YOUR_PANEL_DOMAIN/oauth2/callback/pocketid
|
||||
```
|
||||
|
||||
### OAuth2 Settings in Remnawave
|
||||
|
||||
After creating the OAuth2 application – copy the `Client ID` and `Client Secret`. Insert this data in the corresponding section. And below, enter the list of email addresses for which login will be allowed.
|
||||
|
||||
In the `Plain Domain` field, enter the domain address where your PocketID is located.
|
||||
Just enter the domain name – without the path and `https://`, for example: `pocketid.your-domain.com`
|
||||
|
||||
### Custom Claims (v2.4.0+)
|
||||
|
||||
Remnawave also supports authorization using Custom Claims.
|
||||
When using this method, you do not need to specify an array of email addresses.
|
||||
|
||||
Key
|
||||
|
||||
```
|
||||
remnawaveAccess
|
||||
```
|
||||
|
||||
Value
|
||||
|
||||
```
|
||||
true
|
||||
```
|
||||
|
||||
Accordingly, if a user has this key (`remnawaveAccess: true`) in their token, they will be authorized.
|
||||
43
_panel-docs/help-articles/en/AUTH_METHODS_TELEGRAM.md
Normal file
@@ -0,0 +1,43 @@
|
||||
## Telegram OAuth2
|
||||
|
||||
> This guide is applicable for version **2.7.0** and above.
|
||||
|
||||
To configure the "Login via Telegram" feature, you need a Telegram bot. Additionally, you need to configure the bot for the feature to work correctly.
|
||||
|
||||
### Bot Configuration
|
||||
|
||||
1. Open @BotFather (https://t.me/botfather)
|
||||
2. Open the MiniApp by pressing "Open"
|
||||
3. Select your bot and press `Bot Settings`
|
||||
4. If there is already a domain specified in the `Web Login` section — delete it.
|
||||
5. Press the Switch to OpenID Connect Login button.
|
||||
`If this button is not available, after deleting the domain go back one menu level and repeat from step 3`
|
||||
6. Press Add an Allowed URL.
|
||||
Specify the following values:
|
||||
|
||||
- Trusted Origins: https://panel.domain.com
|
||||
- Redirect URIs: https://panel.domain.com/oauth2/callback/telegram
|
||||
|
||||
### Access Configuration
|
||||
|
||||
After filling in `Client ID`, `Client Secret` and `Frontend Domain`, you need to specify a list of administrator IDs who will have access to login.
|
||||
|
||||
1. From the required account, launch the bot – https://t.me/Get_myidrobot
|
||||
2. In response, the bot will send you your ID, enter it in the corresponding field.
|
||||
|
||||
---
|
||||
|
||||
### Known Error Solutions
|
||||
|
||||
###### Various protections installed on top of the panel (such as cookies, etc.) may not work correctly with `Telegram OAuth2`.
|
||||
|
||||
Use the /oauth2/ path in your reverse proxy to resolve this issue
|
||||
|
||||
###### Error: BOT_DOMAIN_INVALID
|
||||
|
||||
This error occurs due to incorrect bot domain configuration – review the "Bot Configuration" section (above). If necessary, repeat this step-by-step process.
|
||||
|
||||
###### Error: Telegram confirmation code not received during login
|
||||
|
||||
Unfortunately, this issue cannot be resolved from the Remnawave side. Try using a bot that was created a while ago or use a different browser.
|
||||
Alternatively, you can try logging in on one of the "official" resources – for example, https://fragment.com. Since the Telegram session within the browser will be shared – you can try logging into the panel.
|
||||
20
_panel-docs/help-articles/en/AUTH_METHODS_YANDEX.md
Normal file
@@ -0,0 +1,20 @@
|
||||
## OAuth2: Yandex
|
||||
|
||||
The Yandex authentication method is not recommended for use.
|
||||
|
||||
### Creating an OAuth Application
|
||||
|
||||
You need to create an OAuth application in Yandex.
|
||||
|
||||
Follow the link to create an application: https://oauth.yandex.com/client/new
|
||||
|
||||
On the second step of application creation, select the "Web application" option and enter the `Callback URL`
|
||||
|
||||
```
|
||||
# Replace YOUR_PANEL_DOMAIN with your Remnawave panel address
|
||||
https://YOUR_PANEL_DOMAIN/oauth2/callback/yandex
|
||||
```
|
||||
|
||||
Don't forget to replace `YOUR_PANEL_DOMAIN` with the correct panel address.
|
||||
|
||||
On the third step of creation – make sure to check the box next to `Access to email address`, no other permissions are required.
|
||||
31
_panel-docs/help-articles/en/EDITOR_TEMPLATES_XRAY_JSON.md
Normal file
@@ -0,0 +1,31 @@
|
||||
## Xray JSON Subscription Format
|
||||
|
||||
The Xray JSON format provides native JSON-based subscription support for compatible clients. Simply append `/json` to your subscription URL to enable this format.
|
||||
|
||||
### Supported Applications
|
||||
|
||||
- **v2rayNG** — version 1.8.29 or higher
|
||||
- **V2rayN** — version 6.40 or higher
|
||||
- **Streisand** — all versions
|
||||
- **Happ** — all versions
|
||||
- **V2Box** — all versions
|
||||
- **ktor-client** — all versions
|
||||
|
||||
### Usage Instructions
|
||||
|
||||
**Step 1:** Modify your subscription URL
|
||||
|
||||
Append `/json` to the end of your subscription link:
|
||||
`https://<server>/api/sub/xxxx/json`
|
||||
|
||||
**Step 2:** Verify compatibility
|
||||
|
||||
Ensure your client application meets the minimum version requirements listed above.
|
||||
|
||||
**Alternatively:** Enable JSON At the base path
|
||||
|
||||
Enable the "Serve JSON at base subscription" option in the subscription settings. This will serve the JSON subscription at the base subscription path (without having to append /json).
|
||||
|
||||
### Fallback Behavior
|
||||
|
||||
For clients that don't support the JSON format (such as Base64 or Mihomo-based clients), the subscription will automatically fall back to the standard format compatible with your client.
|
||||
107
_panel-docs/help-articles/en/PAGE_CONFIG_PROFILES.md
Normal file
@@ -0,0 +1,107 @@
|
||||
## Config Profiles
|
||||
|
||||
A Config Profile, in the context of Remnawave, represents a complete server configuration for the [Xray](https://xtls.github.io/en/config/) core.
|
||||
|
||||
In this configuration, you define _inbounds_ that your users will later connect to.
|
||||
|
||||
**The details of Xray configuration setup will not be described here, as this is a topic for independent study - use the official [Xray](https://xtls.github.io/en/config/) documentation to learn about all the capabilities of the core.**
|
||||
|
||||
When creating a new Config Profile, it is created by default with one _inbound_ of type **Shadowsocks**. After the Config Profile is created - you can modify this or add a new _inbound_.
|
||||
|
||||
_Tip: To add a new inbound, for example with the **VLESS** protocol - simply add another object inside the `inbounds:[]` array._
|
||||
|
||||
Currently, Remnawave supports protocols such as: `VLESS`, `Trojan`, `Shadowsocks` (`chacha20-ietf-poly1305`, `2022-blake3-aes-256-gcm`, `aes-128-gcm`, `aes-256-gcm`), `Hysteria2` (client Xray-Json generation only). And also the following transports: `RAW (TCP)`, `XHTTP`, `Websocket`, `HTTPUpgrade`, `gRPC`, `KCP`.
|
||||
|
||||
It's important to note that Remnawave also supports protocols: `Tunnel`, `mixed(socks)`, `wireguard`, `http` - however, the panel will completely ignore them and user management for these protocols will be unavailable. These _inbounds_ will be passed to Xray in the exact form you specify them.
|
||||
|
||||
For the main protocols (`VLESS`, `Trojan`, `Shadowsocks`), Remnawave will manage the list of users that will be inside the server configuration. No additional actions are required on your part.
|
||||
|
||||
---
|
||||
|
||||
### Config Profiles List
|
||||
|
||||
In the general list of Config Profiles, a brief summary is available for each created Config Profile. Under the Config Profile name, you can see the number of active _inbounds_ within it, as well as the number of active **nodes** on which this Config Profile is active. Both icons are clickable - clicking on them will open the corresponding sections.
|
||||
|
||||
When clicking on _inbounds_ - a list of _inbounds_ will open, and for each inbound, it will show on how many internal squads this _inbound_ is activated.
|
||||
When clicking on _nodes_ - a list of _nodes_ where this specific Config Profile is active will open.
|
||||
|
||||
In the additional actions menu (down arrow), options for quick Config Profile viewing, viewing Config Profile with snippets, as well as other service options are available.
|
||||
|
||||
---
|
||||
|
||||
### Config Profile Editor
|
||||
|
||||
The Config Profile editor provides a full-featured JSON editor with syntax checking. Also, when hovering over certain objects, a tooltip with information from the Xray documentation will be available.
|
||||
|
||||
With any changes, the entire configuration is immediately validated by running a lightweight version of the core. Such validation helps prevent trivial errors and typos.
|
||||
|
||||
In the additional menu (at the very bottom, button with three bars), additional options are available. Let's skip the basic things: copy all, select all, and so on - these options are self-explanatory.
|
||||
|
||||
The "**Download from Github**" option will open an additional menu where you can download configuration examples from users. **These examples are not ready-to-use configurations, but are merely examples - keep this in mind.**
|
||||
|
||||
The "**Generate Keys**" option allows you to quickly and conveniently generate necessary key pairs right in the browser - for example, in the case of `Reality`, you will definitely need a `privateKey`, which can be generated in this menu. Other generation options are also available there, which will be useful for `Vless Encryption` - `ML-DSA65` and `ML-KEM768`.
|
||||
|
||||
---
|
||||
|
||||
### Snippets
|
||||
|
||||
When you have many Config Profiles - it can be quite difficult to quickly change small details that are present in all Config Profiles but differ in minor aspects.
|
||||
|
||||
For example, you have several profiles - let's say 10 pieces. In each of the 10, the routing section is the same and you would like to quickly and conveniently replace the rules in all profiles at once. With the snippets functionality, you only need to change the "rule" or "rules" in one place, and then they will automatically be pulled into the profiles.
|
||||
|
||||
Currently, you can predefine array elements for objects such as `outbounds` and `rules`. After creating a snippet, it will be available in one of these objects.
|
||||
|
||||
```
|
||||
{
|
||||
"outbounds": [
|
||||
{
|
||||
"snippet": "snippet-name"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Additional information about them is available by clicking on the question mark in the snippets menu.
|
||||
|
||||
### Flow Control (VLESS)
|
||||
|
||||
_This feature is available only in version 2.3.0 and above._
|
||||
|
||||
By default, Remnawave automatically adds the `flow` parameter for the following configurations: VLESS+TLS, REALITY+RAW, or TCP.
|
||||
|
||||
If you wish to override this behavior, add the `flow` field to the `settings` object.
|
||||
|
||||
```json
|
||||
"settings": {
|
||||
"flow": "",
|
||||
"clients": [],
|
||||
"decryption": "none"
|
||||
},
|
||||
```
|
||||
|
||||
Available values for `flow`:
|
||||
|
||||
- `xtls-rprx-vision`
|
||||
- `""`
|
||||
|
||||
### Kcp with FinalMask
|
||||
|
||||
_This feature is available only in version 2.7.0 and above._
|
||||
|
||||
In some cases, you may need to specify a custom MTU (in the `kcpSettings` object) when using FinalMask. Unfortunately, Xray configuration does not clearly separate client and server MTU values.
|
||||
|
||||
```json
|
||||
{
|
||||
"mtu": 1350
|
||||
}
|
||||
```
|
||||
|
||||
Since Remnawave needs to generate the client-side configuration, we have added a custom field that does not exist in the original Xray configuration.
|
||||
|
||||
```json
|
||||
{
|
||||
"clientMtu": 70
|
||||
}
|
||||
```
|
||||
|
||||
The `clientMtu` parameter (if present) will be converted to `mtu` on the client side. This way, you can set a custom MTU for the client side.
|
||||
43
_panel-docs/help-articles/en/PAGE_EXTERNAL_SQUADS.md
Normal file
@@ -0,0 +1,43 @@
|
||||
## External Squads
|
||||
|
||||
Using external squads, you can override certain settings or templates that users use when requesting a subscription. _A user cannot have more than one active external squad._
|
||||
|
||||
For example, for different user groups, you can set different routing (for Happ, v2rayTUN), and different routing can also be within templates.
|
||||
|
||||
Using the additional menu, you can quickly assign an external squad to all users (or conversely remove all users from an external squad).
|
||||
|
||||
If a user has no external squad selected – global settings from the "**Subscription**" section are used, as well as the "**Default**" client config template.
|
||||
|
||||
---
|
||||
|
||||
Let's smoothly move on to reviewing the settings available in the external squad card.
|
||||
|
||||
### Template Override
|
||||
|
||||
When a user requests a subscription – depending on the client application from which the request came, the user may receive different templates. For example, if the application runs on the Mihomo core – Remnawave will detect this and provide the **Default** template of the **Mihomo** type. (You can manage templates in the corresponding section).
|
||||
|
||||
Inside Remnawave, you can create an infinite number of templates for each type (Mihomo, Stash, Xray Json, Singbox, Clash), but by default, the **Default** template will always be provided.
|
||||
|
||||
**To override this behavior is exactly what this setting inside the external squad exists for.**
|
||||
|
||||
Let's say, for a specific external squad we want to use a _Custom Template_ that belongs to the **Mihomo** type, in this case we select this template in the corresponding section and save the changes. If a request comes from a user who belongs to this external squad – instead of the _Default_ template, they will receive the _Custom Template_.
|
||||
|
||||
If you leave the override field empty – the user who is in this squad will receive the _Default_ template.
|
||||
|
||||
_Please note, template override in the "Response Rules" section has a higher priority than override in this section._
|
||||
|
||||
### Settings (Subscription)
|
||||
|
||||
In this section, general settings that are located in the "Subscription" → "Settings" section are overridden. Accordingly, by overriding settings within the squad, you can override many parameters at once for an entire group of users.
|
||||
|
||||
Keep in mind, if any of the parameters is explicitly overridden (including an empty value) – it will be overridden. Only deletion of the override (trash icon) will cancel the override.
|
||||
|
||||
For example, in general settings my profile header is set as "Remnawave", but for 10 users I want to override it, for example to "Remnawave v.2.x", in this case I override this parameter in this section, and then assign this external squad to the needed 10 users.
|
||||
|
||||
### Hosts
|
||||
|
||||
Based on the logic from the previous point – in this section you can completely override some parameters that you might have noticed in the card of each **host** you created.
|
||||
|
||||
**Values overridden here will be applied to all hosts that the user receives in the subscription.**
|
||||
|
||||
For example, by overriding `vlessRouteId` we can assign a specific value and thus "_route_" an entire group of users (those who will be in this squad). Naturally, the other half of such routing settings is located in the server configuration – the Config Profile.
|
||||
67
_panel-docs/help-articles/en/PAGE_HOSTS.md
Normal file
@@ -0,0 +1,67 @@
|
||||
## Hosts
|
||||
|
||||
In brief, hosts are the client representation of your server configuration. If an **inbound** is required on the server for a successful connection, then on the client side the user needs a **host**.
|
||||
|
||||
A group of hosts (or you could say a _list_) represents a subscription. A subscription is a link, and after adding such a link to a client application, the user sees a list of hosts (servers, if you will). The user can then choose any of them.
|
||||
|
||||
It's important to note that a **host** is primarily just a client interpretation of your server component. For example, if a user has received a subscription (the list of hosts is already in their hands) and you disable this host - the user will **still be able** to connect to the server that this host points to. But upon updating the subscription - they will no longer have this host.
|
||||
|
||||
Since a host is directly bound to an inbound (which is located in the profile) - the host inherits most settings from it. However, in some cases it can be useful to override or supplement these settings - that's what the **advanced** settings section is for.
|
||||
|
||||
---
|
||||
|
||||
When creating a new host or editing an existing one, you have access to two sections: **Basic** and **Advanced** (settings).
|
||||
|
||||
### Basic
|
||||
|
||||
#### Remark
|
||||
|
||||
In this field, you define how this host will be displayed in the client application. Usually, the name of the country the user will be connecting to is written here.
|
||||
|
||||
_Tip: To display a country flag in the client application - add an emoji at the very beginning of the remark._
|
||||
|
||||
#### Inbound Selection (and profile)
|
||||
|
||||
As mentioned above - a host is just a client representation of your server configuration, so selecting an inbound is a mandatory requirement for creating a host. Depending on the number of inbounds, nodes, and profiles, select the appropriate inbound in the selection menu.
|
||||
|
||||
#### Address and Port
|
||||
|
||||
The address is a domain or IP address. In most cases, you need to specify the address or domain of the server the user will be connecting to. The port usually corresponds to the **inbound** port, _in some cases it may differ._
|
||||
|
||||
_You can also enter multiple domain names in the address field - for example: `node-1.com,node-2.com,node-3.com`. You might think that this could theoretically be used for some load balancing, but it's important to note - the user will receive only one of these addresses when requesting a subscription (which specific one they get is determined randomly and is not tied to any load balancing logic). Consequently - until the user updates the subscription in the client application (or unless auto-update triggers) - the user's address will not change._
|
||||
|
||||
#### Tag and Nodes
|
||||
|
||||
These parameters are not visible to the end user, they are more for the panel administrator (you) to make it easier to navigate through created hosts in the future if there are many of them.
|
||||
In particular, selecting a node in this field doesn't play a functional role - **this is only a visual binding for easier navigation in the future.**
|
||||
|
||||
---
|
||||
|
||||
### Advanced
|
||||
|
||||
**In most cases, you don't need to edit anything from this section unless you clearly understand what purposes you're doing it for. Incorrect modification of some parameters may result in your connection not working. Approach editing each item with all seriousness and always double-check settings before applying changes.**
|
||||
|
||||
In this section, we won't go through every item - we'll focus on the main ones.
|
||||
|
||||
#### SNI (ServerNames)
|
||||
|
||||
In some cases, it may be necessary to override the `serverNames` object settings (which are defined within the inbound in the profile) for a specific host.
|
||||
|
||||
Keep in mind, `serverNames` in simple terms is the _password_ by which, for example, **Reality** determines the **validity** of the connection. If you specify an **SNI** in this field, for example `example.com`, and within the inbound `serverNames` looks like this:
|
||||
|
||||
```json
|
||||
"serverNames": [
|
||||
"example1.com",
|
||||
"example2.com"
|
||||
]
|
||||
```
|
||||
|
||||
Such a connection will not work, as `example.com` is not in the list of allowed `SNI`.
|
||||
|
||||
#### Override SNI from Address
|
||||
|
||||
By default, Remnawave takes the first object from the `serverNames` array (of the inbound) to add SNI to the client host. If you enable this parameter - Remnawave will take the address (which you specified in the **Basic** section) and pass it to the client.
|
||||
|
||||
Among other items in this section, the `vlessRouteId` field is also worth noting, which is a small abstraction layer over Xray Core and provides you with a simple way to use the `vlessRoute` functionality that Xray provides. <a href="https://xtls.github.io/en/config/routing.html#ruleobject">Learn more about routing rules.</a>
|
||||
|
||||
---
|
||||
21
_panel-docs/help-articles/en/PAGE_INTERNAL_SQUADS.md
Normal file
@@ -0,0 +1,21 @@
|
||||
## Internal Squads
|
||||
|
||||
The main purpose of internal squads is **access control** for users.
|
||||
|
||||
Internal squads are directly linked to **profiles** and their **inbounds**. You can assign them as many active inbounds as needed (which are located inside profiles). And since profiles and their inbounds are directly linked to nodes – using an internal squad, we can finely control which users or groups of users can have access to nodes.
|
||||
|
||||
---
|
||||
|
||||
In each squad's card (in the general list), you can see the number of active inbounds, as well as the number of members in this squad (users who belong to it).
|
||||
|
||||
By clicking on the additional actions button (in the squad card), you can also quickly add or remove all users. If you need to assign a squad to _specific_ users – you can do this in the **"Users"** section.
|
||||
|
||||
Managing users and nodes that can be accessible to them can sometimes be very confusing – use the **"Available Nodes"** button to quickly see which nodes are available to this squad. Let me remind you that when creating or modifying a **node**, we also select which **profile** will be used and which **inbounds** from it will be active on the node. And since we also select **inbounds** inside the squad, we can use these relationships to determine specific nodes that this squad (and consequently its members) will have access to.
|
||||
|
||||
---
|
||||
|
||||
For example, we have two user groups: **free** and **paid**. And we want **free** users to have access to _server group #1_, and paid users to have access to both _server group #1_ and additionally to _server group #2_.
|
||||
|
||||
For this purpose, we create two squads: **Free** and **Premium**, and inside each of them we select the corresponding inbounds.
|
||||
|
||||
And let's say we're creating a user – in this case, if we have a free user – we simply activate the **Free** internal squad for them. And when we have a paid user – we activate both squads – **Free** and **Premium** (if the user needs access to all nodes/inbounds). But we can also activate only one squad for a paid user – **Premium**, in which case the user will not have access to the nodes/inbounds from the **Free** group.
|
||||
115
_panel-docs/help-articles/fa/AUTH_METHODS_GENERIC.md
Normal file
@@ -0,0 +1,115 @@
|
||||
# احراز هویت Generic OAuth2
|
||||
|
||||
Generic OAuth2 به شما امکان میدهد هر ارائهدهنده هویت سازگار با OAuth2 را به Remnawave متصل کنید. این زمانی مفید است که میخواهید از ارائهدهندگانی استفاده کنید که یکپارچگی اختصاصی ندارند (مانند Authentik، Authelia، Zitadel، Google، Microsoft و غیره).
|
||||
|
||||
## پیشنیازها
|
||||
|
||||
1. یک ارائهدهنده هویت سازگار با OAuth2
|
||||
2. دسترسی مدیریتی برای ایجاد کلاینتها/برنامههای OAuth2
|
||||
3. ارائهدهنده باید از claim مربوط به `email` در توکنها پشتیبانی کند
|
||||
|
||||
## مراحل پیکربندی
|
||||
|
||||
### 1. ایجاد برنامه OAuth2 در ارائهدهنده شما
|
||||
|
||||
مراحل دقیق بسته به ارائهدهنده متفاوت است، اما به طور کلی باید:
|
||||
|
||||
1. به کنسول مدیریت ارائهدهنده هویت خود وارد شوید
|
||||
2. یک برنامه OAuth2/OIDC جدید ایجاد کنید
|
||||
3. پیکربندی کنید:
|
||||
- **نوع برنامه**: Web Application
|
||||
- **نوع Grant**: Authorization Code
|
||||
- **Redirect URI**: `https://your-panel-domain.com/oauth2/callback/generic`
|
||||
4. **Client ID** و **Client Secret** را یادداشت کنید
|
||||
5. **Authorization URL** و **Token URL** ارائهدهنده را پیدا کنید (معمولاً در مستندات یا well-known endpoint)
|
||||
|
||||
### 2. یافتن URLهای ارائهدهنده
|
||||
|
||||
اکثر ارائهدهندگان این endpointها را مستند کردهاند. الگوهای رایج:
|
||||
|
||||
| ارائهدهنده | Authorization URL | Token URL |
|
||||
| ----------- | ------------------------------------------------------------------ | -------------------------------------------------------------- |
|
||||
| Google | `https://accounts.google.com/o/oauth2/v2/auth` | `https://oauth2.googleapis.com/token` |
|
||||
| Microsoft | `https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize` | `https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token` |
|
||||
| Authentik | `https://your-authentik.com/application/o/authorize/` | `https://your-authentik.com/application/o/token/` |
|
||||
| Authelia | `https://your-authelia.com/api/oidc/authorization` | `https://your-authelia.com/api/oidc/token` |
|
||||
| Zitadel | `https://your-zitadel.com/oauth/v2/authorize` | `https://your-zitadel.com/oauth/v2/token` |
|
||||
|
||||
### 3. پشتیبانی از PKCE
|
||||
|
||||
**PKCE (Proof Key for Code Exchange)** یک لایه امنیتی اضافی به جریان OAuth2 اضافه میکند. این گزینه را فعال کنید اگر:
|
||||
|
||||
- ارائهدهنده شما از PKCE پشتیبانی میکند (اکثر ارائهدهندگان مدرن پشتیبانی میکنند)
|
||||
- میخواهید امنیت بیشتری در برابر حملات رهگیری کد احراز هویت داشته باشید
|
||||
- ارائهدهنده شما برای کلاینتهای عمومی PKCE را الزامی کرده است
|
||||
|
||||
> **توصیه**: اگر ارائهدهنده شما از آن پشتیبانی میکند، PKCE را فعال کنید.
|
||||
|
||||
## پیکربندی Remnawave
|
||||
|
||||
| فیلد | توضیحات |
|
||||
| --------------------- | ------------------------------------------------------------------------------ |
|
||||
| **Client ID** | شناسه کلاینت/برنامه از ارائهدهنده OAuth2 شما |
|
||||
| **Client Secret** | رمز کلاینت از ارائهدهنده OAuth2 شما |
|
||||
| **Authorization URL** | URL endpoint احراز هویت OAuth2 (مثلاً `https://provider.com/oauth2/authorize`) |
|
||||
| **Token URL** | URL endpoint توکن OAuth2 (مثلاً `https://provider.com/oauth2/token`) |
|
||||
| **Frontend Domain** | دامنه پنل Remnawave شما بدون `https://` (مثلاً `panel.example.com`) |
|
||||
| **With PKCE** | فعالسازی PKCE (Proof Key for Code Exchange) برای امنیت بیشتر |
|
||||
| **Allowed Emails** | لیست آدرسهای ایمیل مجاز برای ورود |
|
||||
|
||||
## کنترل دسترسی
|
||||
|
||||
میتوانید دسترسی را با **یکی از دو روش** (یا هر دو) کنترل کنید:
|
||||
|
||||
### گزینه A: استفاده از Allowed Emails
|
||||
|
||||
لیستی از آدرسهای ایمیل مجاز را در تنظیمات Remnawave مشخص کنید. فقط کاربرانی که ایمیل آنها در این لیست است میتوانند وارد شوند.
|
||||
|
||||
### گزینه B: استفاده از Custom Claim
|
||||
|
||||
اگر لیست **Allowed Emails** خالی باشد، Remnawave یک claim سفارشی را در توکن بررسی میکند:
|
||||
|
||||
| کلید | مقدار |
|
||||
| ----------------- | ------ |
|
||||
| `remnawaveAccess` | `true` |
|
||||
|
||||
اگر توکن کاربر حاوی `remnawaveAccess: true` باشد، احراز هویت میشود.
|
||||
|
||||
> **توجه**: باید ارائهدهنده هویت خود را برای اضافه کردن این claim سفارشی به توکن پیکربندی کنید. مراحل دقیق بسته به ارائهدهنده متفاوت است — معمولاً این کار از طریق تنظیمات "mappers"، "claims" یا "token customization" انجام میشود.
|
||||
|
||||
## عیبیابی
|
||||
|
||||
### "Invalid redirect URI"
|
||||
|
||||
مطمئن شوید که redirect URI در ارائهدهنده شما دقیقاً مطابقت دارد: `https://your-panel-domain.com/oauth2/callback/generic`
|
||||
|
||||
### "Invalid or missing email claim"
|
||||
|
||||
اطمینان حاصل کنید:
|
||||
|
||||
- کاربر یک آدرس ایمیل در ارائهدهنده شما تنظیم کرده است
|
||||
- scope مربوط به `email` درخواست و اعطا شده است
|
||||
- ارائهدهنده شما claim مربوط به `email` را در توکن قرار میدهد
|
||||
|
||||
### "State mismatch"
|
||||
|
||||
کوکیهای مرورگر را پاک کنید و دوباره امتحان کنید. این میتواند در صورت قطع شدن جریان احراز هویت رخ دهد.
|
||||
|
||||
### "Token exchange failed"
|
||||
|
||||
بررسی کنید:
|
||||
|
||||
- **Token URL** صحیح است
|
||||
- **Client ID** و **Client Secret** صحیح هستند
|
||||
- endpoint توکن ارائهدهنده شما از سرور Remnawave قابل دسترسی است
|
||||
|
||||
### "Access denied"
|
||||
|
||||
ایمیل کاربر در لیست **Allowed Emails** نیست. آدرس ایمیل او را برای اعطای دسترسی اضافه کنید.
|
||||
|
||||
### خطاهای مربوط به PKCE
|
||||
|
||||
اگر خطاهای مربوط به `code_verifier` یا `code_challenge` دریافت میکنید:
|
||||
|
||||
- سعی کنید **With PKCE** را غیرفعال کنید اگر ارائهدهنده شما از آن پشتیبانی نمیکند
|
||||
- یا اگر ارائهدهنده شما آن را الزامی کرده، فعالش کنید
|
||||
19
_panel-docs/help-articles/fa/AUTH_METHODS_GITHUB.md
Normal file
@@ -0,0 +1,19 @@
|
||||
## OAuth2: GitHub
|
||||
|
||||
### Creating an OAuth Application
|
||||
|
||||
First, you need to create an OAuth application.
|
||||
Follow the link to create an application: [https://github.com/settings/applications/new](https://github.com/settings/applications/new)
|
||||
|
||||
In the `Authorization callback URL` field, enter the address of your panel.
|
||||
|
||||
```bash
|
||||
# Replace YOUR_PANEL_DOMAIN with your panel address
|
||||
https://YOUR_PANEL_DOMAIN/oauth2/callback/github
|
||||
```
|
||||
|
||||
Don't forget to replace `YOUR_PANEL_DOMAIN` with the correct panel address.
|
||||
|
||||
### OAuth2 Settings in Remnawave
|
||||
|
||||
After creating the OAuth2 application – copy the `Client ID` and `Client Secret`. Insert this data in the corresponding section. And below, enter the list of email addresses for which login will be allowed.
|
||||
80
_panel-docs/help-articles/fa/AUTH_METHODS_KEYCLOAK.md
Normal file
@@ -0,0 +1,80 @@
|
||||
# احراز هویت Keycloak
|
||||
|
||||
Keycloak یک راهحل متنباز مدیریت هویت و دسترسی است که قابلیتهای Single Sign-On (SSO) را فراهم میکند.
|
||||
|
||||
## پیشنیازها
|
||||
|
||||
1. سرور Keycloak در حال اجرا
|
||||
2. دسترسی مدیر برای ایجاد کلاینتها
|
||||
|
||||
## مراحل پیکربندی
|
||||
|
||||
### 1. ایجاد کلاینت در Keycloak
|
||||
|
||||
1. وارد کنسول مدیریت Keycloak شوید
|
||||
2. realm خود را انتخاب کنید (یا یک realm جدید ایجاد کنید)
|
||||
3. به **Clients** → **Create client** بروید
|
||||
4. پیکربندی کنید:
|
||||
- **Client ID**: `remnawave` (یا نام دلخواه شما)
|
||||
- **Client Protocol**: `openid-connect`
|
||||
- **Client authentication**: `ON`
|
||||
5. **Valid redirect URIs** را تنظیم کنید: `https://your-panel-domain.com/oauth2/callback/keycloak`
|
||||
6. **Web Origins** را تنظیم کنید: `https://your-panel-domain.com`
|
||||
7. کلاینت را ذخیره کنید
|
||||
|
||||
### 2. دریافت اعتبارنامه کلاینت
|
||||
|
||||
1. به **Clients** → کلاینت شما → تب **Credentials** بروید
|
||||
2. **Client secret** را کپی کنید
|
||||
|
||||
### 3. پیکربندی کنترل دسترسی
|
||||
|
||||
شما میتوانید با استفاده از **یکی از دو روش** (یا هر دو) دسترسی را کنترل کنید:
|
||||
|
||||
#### گزینه A: استفاده از Claim (توصیه شده)
|
||||
|
||||
یک claim سفارشی `remnawaveAccess: true` به توکن اضافه کنید:
|
||||
|
||||
1. به **Clients** → کلاینت شما → تب **Client scopes** بروید
|
||||
2. روی `<your-client-id>-dedicated` کلیک کنید
|
||||
3. به تب **Mappers** → **Add mapper** → **By configuration** بروید
|
||||
4. **Hardcoded claim** را انتخاب کنید
|
||||
5. پیکربندی کنید:
|
||||
- **Name**: `remnawaveAccess`
|
||||
- **Token Claim Name**: `remnawaveAccess`
|
||||
- **Claim value**: `true`
|
||||
- **Claim JSON Type**: `boolean`
|
||||
- **Add to ID token**: `ON`
|
||||
- **Add to access token**: `ON`
|
||||
6. ذخیره کنید
|
||||
|
||||
#### گزینه B: استفاده از ایمیلهای مجاز
|
||||
|
||||
به جای پیکربندی claim، میتوانید لیستی از آدرسهای ایمیل مجاز را در تنظیمات Remnawave مشخص کنید. فقط کاربرانی که ایمیل آنها در این لیست است میتوانند وارد شوند.
|
||||
|
||||
## پیکربندی Remnawave
|
||||
|
||||
| فیلد | توضیحات |
|
||||
|------|---------|
|
||||
| **Keycloak Domain** | دامنه سرور Keycloak بدون `https://` (مثلاً `keycloak.example.com`) |
|
||||
| **Frontend Domain** | دامنه پنل Remnawave بدون `https://` (مثلاً `panel.example.com`) |
|
||||
| **Realm** | نام realm در Keycloak (مثلاً `master`) |
|
||||
| **Client ID** | شناسه کلاینتی که ایجاد کردید |
|
||||
| **Client Secret** | رمز کلاینت از تب Credentials |
|
||||
| **Allowed Emails** | لیست آدرسهای ایمیل مجاز برای ورود (در صورت استفاده از claim اختیاری است) |
|
||||
|
||||
## عیبیابی
|
||||
|
||||
### "Email is not in the allowed list and remnawaveAccess claim is not present"
|
||||
مطمئن شوید که یکی از شرایط زیر برقرار است:
|
||||
- کاربر claim `remnawaveAccess: true` را از طریق mapper پیکربندی کرده است، یا
|
||||
- ایمیل کاربر به لیست Allowed Emails در تنظیمات Remnawave اضافه شده است
|
||||
|
||||
### "Invalid redirect URI"
|
||||
بررسی کنید که redirect URI در Keycloak دقیقاً مطابقت داشته باشد: `https://your-panel-domain.com/oauth2/callback/keycloak`
|
||||
|
||||
### "State mismatch"
|
||||
کوکیهای مرورگر را پاک کنید و دوباره امتحان کنید. این میتواند اتفاق بیفتد اگر جریان احراز هویت قطع شده باشد.
|
||||
|
||||
### "Invalid or missing email claim"
|
||||
مطمئن شوید که کاربر در Keycloak آدرس ایمیل دارد و email scope فعال است.
|
||||
21
_panel-docs/help-articles/fa/AUTH_METHODS_PASSWORD.md
Normal file
@@ -0,0 +1,21 @@
|
||||
## Authentication Method: Password
|
||||
|
||||
### Changing or Resetting Password
|
||||
|
||||
Use `Rescue CLI` to reset or change the password.
|
||||
|
||||
```bash
|
||||
docker exec -it remnawave remnawave
|
||||
```
|
||||
|
||||
After entering `Rescue CLI`, select the `Reset superadmin` option.
|
||||
|
||||
### Emergency Password Authentication Enable
|
||||
|
||||
If you have disabled the "Password" authentication method but later lost access to one of the other authentication methods – you can enable the "Password" authentication method using `Rescue CLI`
|
||||
|
||||
```bash
|
||||
docker exec -it remnawave remnawave
|
||||
```
|
||||
|
||||
After entering `Rescue CLI`, select the `Enable password authentication` option.
|
||||
36
_panel-docs/help-articles/fa/AUTH_METHODS_POCKETID.md
Normal file
@@ -0,0 +1,36 @@
|
||||
## OAuth2: PocketID
|
||||
|
||||
### Creating an OIDC Client
|
||||
|
||||
Log in to the PocketID admin panel and navigate to: `Settings` → `OIDC Clients` → `Add OIDC Client`
|
||||
|
||||
```
|
||||
# Replace YOUR_PANEL_DOMAIN with your Remnawave panel address
|
||||
https://YOUR_PANEL_DOMAIN/oauth2/callback/pocketid
|
||||
```
|
||||
|
||||
### OAuth2 Settings in Remnawave
|
||||
|
||||
After creating the OAuth2 application – copy the `Client ID` and `Client Secret`. Insert this data in the corresponding section. And below, enter the list of email addresses for which login will be allowed.
|
||||
|
||||
In the `Plain Domain` field, enter the domain address where your PocketID is located.
|
||||
Just enter the domain name – without the path and `https://`, for example: `pocketid.your-domain.com`
|
||||
|
||||
### Custom Claims (v2.4.0+)
|
||||
|
||||
Remnawave also supports authorization using Custom Claims.
|
||||
When using this method, you do not need to specify an array of email addresses.
|
||||
|
||||
Key
|
||||
|
||||
```
|
||||
remnawaveAccess
|
||||
```
|
||||
|
||||
Value
|
||||
|
||||
```
|
||||
true
|
||||
```
|
||||
|
||||
Accordingly, if a user has this key (`remnawaveAccess: true`) in their token, they will be authorized.
|
||||
43
_panel-docs/help-articles/fa/AUTH_METHODS_TELEGRAM.md
Normal file
@@ -0,0 +1,43 @@
|
||||
## Telegram OAuth2
|
||||
|
||||
> این راهنما برای نسخه **2.7.0** و بالاتر قابل استفاده است.
|
||||
|
||||
برای پیکربندی قابلیت «ورود از طریق تلگرام»، شما به یک ربات تلگرام نیاز دارید. همچنین باید ربات را بهصورت اضافی پیکربندی کنید تا این قابلیت بهدرستی کار کند.
|
||||
|
||||
### پیکربندی ربات
|
||||
|
||||
1. @BotFather را باز کنید (https://t.me/botfather)
|
||||
2. MiniApp را با دکمه "Open" باز کنید
|
||||
3. ربات خود را انتخاب کرده و `Bot Settings` را بزنید
|
||||
4. اگر در بخش `Web Login` دامنهای از قبل مشخص شده — آن را حذف کنید.
|
||||
5. دکمه Switch to OpenID Connect Login را بزنید.
|
||||
`اگر این دکمه موجود نیست، پس از حذف دامنه یک سطح به عقب برگردید و مراحل را از مرحله ۳ تکرار کنید`
|
||||
6. دکمه Add an Allowed URL را بزنید.
|
||||
مقادیر زیر را وارد کنید:
|
||||
|
||||
- Trusted Origins: https://panel.domain.com
|
||||
- Redirect URIs: https://panel.domain.com/oauth2/callback/telegram
|
||||
|
||||
### پیکربندی دسترسی
|
||||
|
||||
پس از تکمیل `Client ID`، `Client Secret` و `Frontend Domain`، باید فهرستی از شناسههای مدیرانی که اجازه ورود دارند را مشخص کنید.
|
||||
|
||||
1. از حساب مورد نظر، ربات را اجرا کنید – https://t.me/Get_myidrobot
|
||||
2. ربات در پاسخ شناسه شما را ارسال میکند، آن را در فیلد مربوطه وارد کنید.
|
||||
|
||||
---
|
||||
|
||||
### راهحل خطاهای شناختهشده
|
||||
|
||||
###### محافظتهای مختلفی که روی پنل نصب شدهاند (مانند کوکیها و غیره) ممکن است با `Telegram OAuth2` بهدرستی کار نکنند.
|
||||
|
||||
از مسیر /oauth2/ در ریورس پروکسی خود برای حل این مشکل استفاده کنید
|
||||
|
||||
###### خطا: BOT_DOMAIN_INVALID
|
||||
|
||||
این خطا به دلیل پیکربندی نادرست دامنه ربات رخ میدهد — بخش «پیکربندی ربات» (بالا) را بررسی کنید. در صورت نیاز، مراحل را دوباره بهترتیب انجام دهید.
|
||||
|
||||
###### خطا: کد تأیید تلگرام هنگام ورود دریافت نمیشود
|
||||
|
||||
متأسفانه این مشکل از سمت Remnawave قابل حل نیست. سعی کنید از رباتی استفاده کنید که مدتها پیش ایجاد شده یا از مرورگر دیگری استفاده کنید.
|
||||
همچنین میتوانید سعی کنید در یکی از منابع «رسمی» وارد شوید — مثلاً https://fragment.com. از آنجا که نشست تلگرام در مرورگر مشترک است — میتوانید سپس وارد پنل شوید.
|
||||
20
_panel-docs/help-articles/fa/AUTH_METHODS_YANDEX.md
Normal file
@@ -0,0 +1,20 @@
|
||||
## OAuth2: Yandex
|
||||
|
||||
The Yandex authentication method is not recommended for use.
|
||||
|
||||
### Creating an OAuth Application
|
||||
|
||||
You need to create an OAuth application in Yandex.
|
||||
|
||||
Follow the link to create an application: https://oauth.yandex.com/client/new
|
||||
|
||||
On the second step of application creation, select the "Web application" option and enter the `Callback URL`
|
||||
|
||||
```
|
||||
# Replace YOUR_PANEL_DOMAIN with your Remnawave panel address
|
||||
https://YOUR_PANEL_DOMAIN/oauth2/callback/yandex
|
||||
```
|
||||
|
||||
Don't forget to replace `YOUR_PANEL_DOMAIN` with the correct panel address.
|
||||
|
||||
On the third step of creation – make sure to check the box next to `Access to email address`, no other permissions are required.
|
||||
31
_panel-docs/help-articles/fa/EDITOR_TEMPLATES_XRAY_JSON.md
Normal file
@@ -0,0 +1,31 @@
|
||||
## Xray JSON Subscription Format
|
||||
|
||||
The Xray JSON format provides native JSON-based subscription support for compatible clients. Simply append `/json` to your subscription URL to enable this format.
|
||||
|
||||
### Supported Applications
|
||||
|
||||
- **v2rayNG** — version 1.8.29 or higher
|
||||
- **V2rayN** — version 6.40 or higher
|
||||
- **Streisand** — all versions
|
||||
- **Happ** — all versions
|
||||
- **V2Box** — all versions
|
||||
- **ktor-client** — all versions
|
||||
|
||||
### Usage Instructions
|
||||
|
||||
**Step 1:** Modify your subscription URL
|
||||
|
||||
Append `/json` to the end of your subscription link:
|
||||
`https://<server>/api/sub/xxxx/json`
|
||||
|
||||
**Step 2:** Verify compatibility
|
||||
|
||||
Ensure your client application meets the minimum version requirements listed above.
|
||||
|
||||
**Alternatively:** Enable JSON At the base path
|
||||
|
||||
Enable the "Serve JSON at base subscription" option in the subscription settings. This will serve the JSON subscription at the base subscription path (without having to append /json).
|
||||
|
||||
### Fallback Behavior
|
||||
|
||||
For clients that don't support the JSON format (such as Base64 or Mihomo-based clients), the subscription will automatically fall back to the standard format compatible with your client.
|
||||
107
_panel-docs/help-articles/fa/PAGE_CONFIG_PROFILES.md
Normal file
@@ -0,0 +1,107 @@
|
||||
## Config Profiles
|
||||
|
||||
A Config Profile, in the context of Remnawave, represents a complete server configuration for the [Xray](https://xtls.github.io/en/config/) core.
|
||||
|
||||
In this configuration, you define _inbounds_ that your users will later connect to.
|
||||
|
||||
**The details of Xray configuration setup will not be described here, as this is a topic for independent study - use the official [Xray](https://xtls.github.io/en/config/) documentation to learn about all the capabilities of the core.**
|
||||
|
||||
When creating a new Config Profile, it is created by default with one _inbound_ of type **Shadowsocks**. After the Config Profile is created - you can modify this or add a new _inbound_.
|
||||
|
||||
_Tip: To add a new inbound, for example with the **VLESS** protocol - simply add another object inside the `inbounds:[]` array._
|
||||
|
||||
Currently, Remnawave supports protocols such as: `VLESS`, `Trojan`, `Shadowsocks` (`chacha20-ietf-poly1305`, `2022-blake3-aes-256-gcm`, `aes-128-gcm`, `aes-256-gcm`), `Hysteria2` (client Xray-Json generation only). And also the following transports: `RAW (TCP)`, `XHTTP`, `Websocket`, `HTTPUpgrade`, `gRPC`, `KCP`.
|
||||
|
||||
It's important to note that Remnawave also supports protocols: `Tunnel`, `mixed(socks)`, `wireguard`, `http` - however, the panel will completely ignore them and user management for these protocols will be unavailable. These _inbounds_ will be passed to Xray in the exact form you specify them.
|
||||
|
||||
For the main protocols (`VLESS`, `Trojan`, `Shadowsocks`), Remnawave will manage the list of users that will be inside the server configuration. No additional actions are required on your part.
|
||||
|
||||
---
|
||||
|
||||
### Config Profiles List
|
||||
|
||||
In the general list of Config Profiles, a brief summary is available for each created Config Profile. Under the Config Profile name, you can see the number of active _inbounds_ within it, as well as the number of active **nodes** on which this Config Profile is active. Both icons are clickable - clicking on them will open the corresponding sections.
|
||||
|
||||
When clicking on _inbounds_ - a list of _inbounds_ will open, and for each inbound, it will show on how many internal squads this _inbound_ is activated.
|
||||
When clicking on _nodes_ - a list of _nodes_ where this specific Config Profile is active will open.
|
||||
|
||||
In the additional actions menu (down arrow), options for quick Config Profile viewing, viewing Config Profile with snippets, as well as other service options are available.
|
||||
|
||||
---
|
||||
|
||||
### Config Profile Editor
|
||||
|
||||
The Config Profile editor provides a full-featured JSON editor with syntax checking. Also, when hovering over certain objects, a tooltip with information from the Xray documentation will be available.
|
||||
|
||||
With any changes, the entire configuration is immediately validated by running a lightweight version of the core. Such validation helps prevent trivial errors and typos.
|
||||
|
||||
In the additional menu (at the very bottom, button with three bars), additional options are available. Let's skip the basic things: copy all, select all, and so on - these options are self-explanatory.
|
||||
|
||||
The "**Download from Github**" option will open an additional menu where you can download configuration examples from users. **These examples are not ready-to-use configurations, but are merely examples - keep this in mind.**
|
||||
|
||||
The "**Generate Keys**" option allows you to quickly and conveniently generate necessary key pairs right in the browser - for example, in the case of `Reality`, you will definitely need a `privateKey`, which can be generated in this menu. Other generation options are also available there, which will be useful for `Vless Encryption` - `ML-DSA65` and `ML-KEM768`.
|
||||
|
||||
---
|
||||
|
||||
### Snippets
|
||||
|
||||
When you have many Config Profiles - it can be quite difficult to quickly change small details that are present in all Config Profiles but differ in minor aspects.
|
||||
|
||||
For example, you have several profiles - let's say 10 pieces. In each of the 10, the routing section is the same and you would like to quickly and conveniently replace the rules in all profiles at once. With the snippets functionality, you only need to change the "rule" or "rules" in one place, and then they will automatically be pulled into the profiles.
|
||||
|
||||
Currently, you can predefine array elements for objects such as `outbounds` and `rules`. After creating a snippet, it will be available in one of these objects.
|
||||
|
||||
```
|
||||
{
|
||||
"outbounds": [
|
||||
{
|
||||
"snippet": "snippet-name"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Additional information about them is available by clicking on the question mark in the snippets menu.
|
||||
|
||||
### Flow Control (VLESS)
|
||||
|
||||
_This feature is available only in version 2.3.0 and above._
|
||||
|
||||
By default, Remnawave automatically adds the `flow` parameter for the following configurations: VLESS+TLS, REALITY+RAW, or TCP.
|
||||
|
||||
If you wish to override this behavior, add the `flow` field to the `settings` object.
|
||||
|
||||
```json
|
||||
"settings": {
|
||||
"flow": "",
|
||||
"clients": [],
|
||||
"decryption": "none"
|
||||
},
|
||||
```
|
||||
|
||||
Available values for `flow`:
|
||||
|
||||
- `xtls-rprx-vision`
|
||||
- `""`
|
||||
|
||||
### Kcp with FinalMask
|
||||
|
||||
_This feature is available only in version 2.7.0 and above._
|
||||
|
||||
In some cases, you may need to specify a custom MTU (in the `kcpSettings` object) when using FinalMask. Unfortunately, Xray configuration does not clearly separate client and server MTU values.
|
||||
|
||||
```json
|
||||
{
|
||||
"mtu": 1350
|
||||
}
|
||||
```
|
||||
|
||||
Since Remnawave needs to generate the client-side configuration, we have added a custom field that does not exist in the original Xray configuration.
|
||||
|
||||
```json
|
||||
{
|
||||
"clientMtu": 70
|
||||
}
|
||||
```
|
||||
|
||||
The `clientMtu` parameter (if present) will be converted to `mtu` on the client side. This way, you can set a custom MTU for the client side.
|
||||
43
_panel-docs/help-articles/fa/PAGE_EXTERNAL_SQUADS.md
Normal file
@@ -0,0 +1,43 @@
|
||||
## External Squads
|
||||
|
||||
Using external squads, you can override certain settings or templates that users use when requesting a subscription. _A user cannot have more than one active external squad._
|
||||
|
||||
For example, for different user groups, you can set different routing (for Happ, v2rayTUN), and different routing can also be within templates.
|
||||
|
||||
Using the additional menu, you can quickly assign an external squad to all users (or conversely remove all users from an external squad).
|
||||
|
||||
If a user has no external squad selected – global settings from the "**Subscription**" section are used, as well as the "**Default**" client config template.
|
||||
|
||||
---
|
||||
|
||||
Let's smoothly move on to reviewing the settings available in the external squad card.
|
||||
|
||||
### Template Override
|
||||
|
||||
When a user requests a subscription – depending on the client application from which the request came, the user may receive different templates. For example, if the application runs on the Mihomo core – Remnawave will detect this and provide the **Default** template of the **Mihomo** type. (You can manage templates in the corresponding section).
|
||||
|
||||
Inside Remnawave, you can create an infinite number of templates for each type (Mihomo, Stash, Xray Json, Singbox, Clash), but by default, the **Default** template will always be provided.
|
||||
|
||||
**To override this behavior is exactly what this setting inside the external squad exists for.**
|
||||
|
||||
Let's say, for a specific external squad we want to use a _Custom Template_ that belongs to the **Mihomo** type, in this case we select this template in the corresponding section and save the changes. If a request comes from a user who belongs to this external squad – instead of the _Default_ template, they will receive the _Custom Template_.
|
||||
|
||||
If you leave the override field empty – the user who is in this squad will receive the _Default_ template.
|
||||
|
||||
_Please note, template override in the "Response Rules" section has a higher priority than override in this section._
|
||||
|
||||
### Settings (Subscription)
|
||||
|
||||
In this section, general settings that are located in the "Subscription" → "Settings" section are overridden. Accordingly, by overriding settings within the squad, you can override many parameters at once for an entire group of users.
|
||||
|
||||
Keep in mind, if any of the parameters is explicitly overridden (including an empty value) – it will be overridden. Only deletion of the override (trash icon) will cancel the override.
|
||||
|
||||
For example, in general settings my profile header is set as "Remnawave", but for 10 users I want to override it, for example to "Remnawave v.2.x", in this case I override this parameter in this section, and then assign this external squad to the needed 10 users.
|
||||
|
||||
### Hosts
|
||||
|
||||
Based on the logic from the previous point – in this section you can completely override some parameters that you might have noticed in the card of each **host** you created.
|
||||
|
||||
**Values overridden here will be applied to all hosts that the user receives in the subscription.**
|
||||
|
||||
For example, by overriding `vlessRouteId` we can assign a specific value and thus "_route_" an entire group of users (those who will be in this squad). Naturally, the other half of such routing settings is located in the server configuration – the Config Profile.
|
||||
67
_panel-docs/help-articles/fa/PAGE_HOSTS.md
Normal file
@@ -0,0 +1,67 @@
|
||||
## Hosts
|
||||
|
||||
In brief, hosts are the client representation of your server configuration. If an **inbound** is required on the server for a successful connection, then on the client side the user needs a **host**.
|
||||
|
||||
A group of hosts (or you could say a _list_) represents a subscription. A subscription is a link, and after adding such a link to a client application, the user sees a list of hosts (servers, if you will). The user can then choose any of them.
|
||||
|
||||
It's important to note that a **host** is primarily just a client interpretation of your server component. For example, if a user has received a subscription (the list of hosts is already in their hands) and you disable this host - the user will **still be able** to connect to the server that this host points to. But upon updating the subscription - they will no longer have this host.
|
||||
|
||||
Since a host is directly bound to an inbound (which is located in the profile) - the host inherits most settings from it. However, in some cases it can be useful to override or supplement these settings - that's what the **advanced** settings section is for.
|
||||
|
||||
---
|
||||
|
||||
When creating a new host or editing an existing one, you have access to two sections: **Basic** and **Advanced** (settings).
|
||||
|
||||
### Basic
|
||||
|
||||
#### Remark
|
||||
|
||||
In this field, you define how this host will be displayed in the client application. Usually, the name of the country the user will be connecting to is written here.
|
||||
|
||||
_Tip: To display a country flag in the client application - add an emoji at the very beginning of the remark._
|
||||
|
||||
#### Inbound Selection (and profile)
|
||||
|
||||
As mentioned above - a host is just a client representation of your server configuration, so selecting an inbound is a mandatory requirement for creating a host. Depending on the number of inbounds, nodes, and profiles, select the appropriate inbound in the selection menu.
|
||||
|
||||
#### Address and Port
|
||||
|
||||
The address is a domain or IP address. In most cases, you need to specify the address or domain of the server the user will be connecting to. The port usually corresponds to the **inbound** port, _in some cases it may differ._
|
||||
|
||||
_You can also enter multiple domain names in the address field - for example: `node-1.com,node-2.com,node-3.com`. You might think that this could theoretically be used for some load balancing, but it's important to note - the user will receive only one of these addresses when requesting a subscription (which specific one they get is determined randomly and is not tied to any load balancing logic). Consequently - until the user updates the subscription in the client application (or unless auto-update triggers) - the user's address will not change._
|
||||
|
||||
#### Tag and Nodes
|
||||
|
||||
These parameters are not visible to the end user, they are more for the panel administrator (you) to make it easier to navigate through created hosts in the future if there are many of them.
|
||||
In particular, selecting a node in this field doesn't play a functional role - **this is only a visual binding for easier navigation in the future.**
|
||||
|
||||
---
|
||||
|
||||
### Advanced
|
||||
|
||||
**In most cases, you don't need to edit anything from this section unless you clearly understand what purposes you're doing it for. Incorrect modification of some parameters may result in your connection not working. Approach editing each item with all seriousness and always double-check settings before applying changes.**
|
||||
|
||||
In this section, we won't go through every item - we'll focus on the main ones.
|
||||
|
||||
#### SNI (ServerNames)
|
||||
|
||||
In some cases, it may be necessary to override the `serverNames` object settings (which are defined within the inbound in the profile) for a specific host.
|
||||
|
||||
Keep in mind, `serverNames` in simple terms is the _password_ by which, for example, **Reality** determines the **validity** of the connection. If you specify an **SNI** in this field, for example `example.com`, and within the inbound `serverNames` looks like this:
|
||||
|
||||
```json
|
||||
"serverNames": [
|
||||
"example1.com",
|
||||
"example2.com"
|
||||
]
|
||||
```
|
||||
|
||||
Such a connection will not work, as `example.com` is not in the list of allowed `SNI`.
|
||||
|
||||
#### Override SNI from Address
|
||||
|
||||
By default, Remnawave takes the first object from the `serverNames` array (of the inbound) to add SNI to the client host. If you enable this parameter - Remnawave will take the address (which you specified in the **Basic** section) and pass it to the client.
|
||||
|
||||
Among other items in this section, the `vlessRouteId` field is also worth noting, which is a small abstraction layer over Xray Core and provides you with a simple way to use the `vlessRoute` functionality that Xray provides. <a href="https://xtls.github.io/en/config/routing.html#ruleobject">Learn more about routing rules.</a>
|
||||
|
||||
---
|
||||
21
_panel-docs/help-articles/fa/PAGE_INTERNAL_SQUADS.md
Normal file
@@ -0,0 +1,21 @@
|
||||
## Internal Squads
|
||||
|
||||
The main purpose of internal squads is **access control** for users.
|
||||
|
||||
Internal squads are directly linked to **profiles** and their **inbounds**. You can assign them as many active inbounds as needed (which are located inside profiles). And since profiles and their inbounds are directly linked to nodes – using an internal squad, we can finely control which users or groups of users can have access to nodes.
|
||||
|
||||
---
|
||||
|
||||
In each squad's card (in the general list), you can see the number of active inbounds, as well as the number of members in this squad (users who belong to it).
|
||||
|
||||
By clicking on the additional actions button (in the squad card), you can also quickly add or remove all users. If you need to assign a squad to _specific_ users – you can do this in the **"Users"** section.
|
||||
|
||||
Managing users and nodes that can be accessible to them can sometimes be very confusing – use the **"Available Nodes"** button to quickly see which nodes are available to this squad. Let me remind you that when creating or modifying a **node**, we also select which **profile** will be used and which **inbounds** from it will be active on the node. And since we also select **inbounds** inside the squad, we can use these relationships to determine specific nodes that this squad (and consequently its members) will have access to.
|
||||
|
||||
---
|
||||
|
||||
For example, we have two user groups: **free** and **paid**. And we want **free** users to have access to _server group #1_, and paid users to have access to both _server group #1_ and additionally to _server group #2_.
|
||||
|
||||
For this purpose, we create two squads: **Free** and **Premium**, and inside each of them we select the corresponding inbounds.
|
||||
|
||||
And let's say we're creating a user – in this case, if we have a free user – we simply activate the **Free** internal squad for them. And when we have a paid user – we activate both squads – **Free** and **Premium** (if the user needs access to all nodes/inbounds). But we can also activate only one squad for a paid user – **Premium**, in which case the user will not have access to the nodes/inbounds from the **Free** group.
|
||||
115
_panel-docs/help-articles/ru/AUTH_METHODS_GENERIC.md
Normal file
@@ -0,0 +1,115 @@
|
||||
# Аутентификация через Generic OAuth2
|
||||
|
||||
Generic OAuth2 позволяет подключить любой OAuth2-совместимый провайдер идентификации к Remnawave. Это полезно, когда вы хотите использовать провайдеры, для которых нет специальной интеграции (например, Authentik, Authelia, Zitadel, Google, Microsoft и др.).
|
||||
|
||||
## Требования
|
||||
|
||||
1. OAuth2-совместимый провайдер идентификации
|
||||
2. Права администратора для создания OAuth2 клиентов/приложений
|
||||
3. Провайдер должен поддерживать claim `email` в токенах
|
||||
|
||||
## Шаги настройки
|
||||
|
||||
### 1. Создание OAuth2 приложения в вашем провайдере
|
||||
|
||||
Точные шаги зависят от провайдера, но в целом вам нужно:
|
||||
|
||||
1. Войти в админ-консоль вашего провайдера идентификации
|
||||
2. Создать новое OAuth2/OIDC приложение
|
||||
3. Настроить:
|
||||
- **Тип приложения**: Web Application
|
||||
- **Тип гранта**: Authorization Code
|
||||
- **Redirect URI**: `https://your-panel-domain.com/oauth2/callback/generic`
|
||||
4. Сохранить **Client ID** и **Client Secret**
|
||||
5. Найти **Authorization URL** и **Token URL** провайдера (обычно в документации или well-known endpoint)
|
||||
|
||||
### 2. Поиск URL-адресов провайдера
|
||||
|
||||
У большинства провайдеров эти эндпоинты задокументированы. Типичные примеры:
|
||||
|
||||
| Провайдер | Authorization URL | Token URL |
|
||||
| --------- | ------------------------------------------------------------------ | -------------------------------------------------------------- |
|
||||
| Google | `https://accounts.google.com/o/oauth2/v2/auth` | `https://oauth2.googleapis.com/token` |
|
||||
| Microsoft | `https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize` | `https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token` |
|
||||
| Authentik | `https://your-authentik.com/application/o/authorize/` | `https://your-authentik.com/application/o/token/` |
|
||||
| Authelia | `https://your-authelia.com/api/oidc/authorization` | `https://your-authelia.com/api/oidc/token` |
|
||||
| Zitadel | `https://your-zitadel.com/oauth/v2/authorize` | `https://your-zitadel.com/oauth/v2/token` |
|
||||
|
||||
### 3. Поддержка PKCE
|
||||
|
||||
**PKCE (Proof Key for Code Exchange)** добавляет дополнительный уровень безопасности в OAuth2 поток. Включите эту опцию, если:
|
||||
|
||||
- Ваш провайдер поддерживает PKCE (большинство современных провайдеров поддерживают)
|
||||
- Вы хотите усилить защиту от атак перехвата кода авторизации
|
||||
- Ваш провайдер требует PKCE для публичных клиентов
|
||||
|
||||
> **Рекомендация**: Включите PKCE, если ваш провайдер это поддерживает.
|
||||
|
||||
## Настройка Remnawave
|
||||
|
||||
| Поле | Описание |
|
||||
| --------------------- | ------------------------------------------------------------------------------------ |
|
||||
| **Client ID** | ID клиента/приложения от вашего OAuth2 провайдера |
|
||||
| **Client Secret** | Секрет клиента от вашего OAuth2 провайдера |
|
||||
| **Authorization URL** | URL эндпоинта авторизации OAuth2 (например, `https://provider.com/oauth2/authorize`) |
|
||||
| **Token URL** | URL эндпоинта токена OAuth2 (например, `https://provider.com/oauth2/token`) |
|
||||
| **Frontend Domain** | Домен вашей панели Remnawave без `https://` (например, `panel.example.com`) |
|
||||
| **With PKCE** | Включить PKCE (Proof Key for Code Exchange) для повышенной безопасности |
|
||||
| **Allowed Emails** | Список email-адресов, которым разрешён вход |
|
||||
|
||||
## Контроль доступа
|
||||
|
||||
Вы можете контролировать доступ **одним из двух способов** (или обоими):
|
||||
|
||||
### Вариант A: Использование списка Allowed Emails
|
||||
|
||||
Укажите список разрешённых email-адресов в настройках Remnawave. Только пользователи с email из этого списка смогут войти.
|
||||
|
||||
### Вариант B: Использование Custom Claim
|
||||
|
||||
Если список **Allowed Emails** пуст, Remnawave проверит наличие кастомного claim в токене:
|
||||
|
||||
| Ключ | Значение |
|
||||
| ----------------- | -------- |
|
||||
| `remnawaveAccess` | `true` |
|
||||
|
||||
Если токен пользователя содержит `remnawaveAccess: true`, он будет авторизован.
|
||||
|
||||
> **Примечание**: Вам нужно настроить ваш провайдер идентификации для включения этого кастомного claim в токен. Точные шаги зависят от провайдера — обычно это делается через настройки "mappers", "claims" или "token customization".
|
||||
|
||||
## Устранение неполадок
|
||||
|
||||
### "Invalid redirect URI"
|
||||
|
||||
Убедитесь, что redirect URI в вашем провайдере точно совпадает: `https://your-panel-domain.com/oauth2/callback/generic`
|
||||
|
||||
### "Invalid or missing email claim"
|
||||
|
||||
Проверьте:
|
||||
|
||||
- У пользователя установлен email-адрес в провайдере
|
||||
- Scope `email` запрошен и предоставлен
|
||||
- Ваш провайдер включает claim `email` в токен
|
||||
|
||||
### "State mismatch"
|
||||
|
||||
Очистите куки браузера и попробуйте снова. Это может произойти, если процесс аутентификации был прерван.
|
||||
|
||||
### "Token exchange failed"
|
||||
|
||||
Проверьте:
|
||||
|
||||
- **Token URL** указан правильно
|
||||
- **Client ID** и **Client Secret** корректны
|
||||
- Эндпоинт токена вашего провайдера доступен с сервера Remnawave
|
||||
|
||||
### "Access denied"
|
||||
|
||||
Email пользователя отсутствует в списке **Allowed Emails**. Добавьте его email-адрес для предоставления доступа.
|
||||
|
||||
### Ошибки, связанные с PKCE
|
||||
|
||||
Если вы получаете ошибки, связанные с `code_verifier` или `code_challenge`:
|
||||
|
||||
- Попробуйте отключить **With PKCE**, если ваш провайдер его не поддерживает
|
||||
- Или включите, если ваш провайдер его требует
|
||||
19
_panel-docs/help-articles/ru/AUTH_METHODS_GITHUB.md
Normal file
@@ -0,0 +1,19 @@
|
||||
## OAuth2: Github
|
||||
|
||||
### Создание OAuth приложения
|
||||
|
||||
Для начала вам необходимо создать OAuth приложение.
|
||||
Перейдите по ссылке для создания приложения: [https://github.com/settings/applications/new](https://github.com/settings/applications/new)
|
||||
|
||||
В пункте `Authorization callback URL` введите адрес вашей панели.
|
||||
|
||||
```bash
|
||||
# Замените YOUR_PANEL_DOMAIN на адрес вашей панели
|
||||
https://YOUR_PANEL_DOMAIN/oauth2/callback/github
|
||||
```
|
||||
|
||||
Не забудьте заменить `YOUR_PANEL_DOMAIN` на корректный адрес панели.
|
||||
|
||||
### Настройки OAuth2 в Remnawave
|
||||
|
||||
После создания OAuth2 приложения – скопируйте `Client ID` и `Client Secret`. Вставьте эти данные в соответствующем разделе. А чуть ниже введите список email-адресов для которых будет разрешен вход.
|
||||
80
_panel-docs/help-articles/ru/AUTH_METHODS_KEYCLOAK.md
Normal file
@@ -0,0 +1,80 @@
|
||||
# Аутентификация через Keycloak
|
||||
|
||||
Keycloak - это решение для управления идентификацией и доступом с поддержкой Single Sign-On (SSO).
|
||||
|
||||
## Требования
|
||||
|
||||
1. Работающий сервер Keycloak
|
||||
2. Доступ администратора для создания клиентов
|
||||
|
||||
## Шаги настройки
|
||||
|
||||
### 1. Создание клиента в Keycloak
|
||||
|
||||
1. Войдите в Keycloak Admin Console
|
||||
2. Выберите realm (или создайте новый)
|
||||
3. Перейдите в **Clients** → **Create client**
|
||||
4. Настройте:
|
||||
- **Client ID**: `remnawave` (или другое имя)
|
||||
- **Client Protocol**: `openid-connect`
|
||||
- **Client authentication**: `ON`
|
||||
5. **Valid redirect URIs**: `https://ваш-домен-панели.com/oauth2/callback/keycloak`
|
||||
6. **Web Origins**: `https://ваш-домен-панели.com`
|
||||
7. Сохраните клиент
|
||||
|
||||
### 2. Получение Client Secret
|
||||
|
||||
1. Перейдите в **Clients** → ваш клиент → вкладка **Credentials**
|
||||
2. Скопируйте **Client secret**
|
||||
|
||||
### 3. Настройка контроля доступа
|
||||
|
||||
Вы можете контролировать доступ **одним из двух способов** (или обоими):
|
||||
|
||||
#### Вариант A: Через Claim (Рекомендуется)
|
||||
|
||||
Добавьте claim `remnawaveAccess: true` в токен:
|
||||
|
||||
1. Перейдите в **Clients** → ваш клиент → вкладка **Client scopes**
|
||||
2. Нажмите на `<your-client-id>-dedicated`
|
||||
3. Вкладка **Mappers** → **Add mapper** → **By configuration**
|
||||
4. Выберите **Hardcoded claim**
|
||||
5. Настройте:
|
||||
- **Name**: `remnawaveAccess`
|
||||
- **Token Claim Name**: `remnawaveAccess`
|
||||
- **Claim value**: `true`
|
||||
- **Claim JSON Type**: `boolean`
|
||||
- **Add to ID token**: `ON`
|
||||
- **Add to access token**: `ON`
|
||||
6. Сохраните
|
||||
|
||||
#### Вариант B: Через список email-ов
|
||||
|
||||
Вместо настройки claim вы можете указать список разрешённых email-адресов в настройках Remnawave. Только пользователи с email из этого списка смогут войти.
|
||||
|
||||
## Настройки в Remnawave
|
||||
|
||||
| Поле | Описание |
|
||||
|------|----------|
|
||||
| **Keycloak Domain** | Домен сервера Keycloak без `https://` (например, `keycloak.example.com`) |
|
||||
| **Frontend Domain** | Домен панели Remnawave без `https://` (например, `panel.example.com`) |
|
||||
| **Realm** | Название realm в Keycloak (например, `master`) |
|
||||
| **Client ID** | ID созданного клиента |
|
||||
| **Client Secret** | Секрет из вкладки Credentials |
|
||||
| **Allowed Emails** | Список email-адресов с разрешённым входом (опционально при использовании claim) |
|
||||
|
||||
## Решение проблем
|
||||
|
||||
### "Email is not in the allowed list and remnawaveAccess claim is not present"
|
||||
Убедитесь что выполнено одно из условий:
|
||||
- У пользователя настроен claim `remnawaveAccess: true` через маппер, ИЛИ
|
||||
- Email пользователя добавлен в список Allowed Emails в настройках Remnawave
|
||||
|
||||
### "Invalid redirect URI"
|
||||
Проверьте, что redirect URI точно совпадает: `https://ваш-домен-панели.com/oauth2/callback/keycloak`
|
||||
|
||||
### "State mismatch"
|
||||
Очистите cookies браузера и попробуйте снова. Это может произойти если процесс аутентификации был прерван.
|
||||
|
||||
### "Invalid or missing email claim"
|
||||
Убедитесь, что у пользователя указан email в Keycloak и включён scope email.
|
||||
21
_panel-docs/help-articles/ru/AUTH_METHODS_PASSWORD.md
Normal file
@@ -0,0 +1,21 @@
|
||||
## Метод входа: пароль
|
||||
|
||||
### Изменение или сброс пароля
|
||||
|
||||
Используйте `Rescue CLI` для сброса или изменения пароля.
|
||||
|
||||
```bash
|
||||
docker exec -it remnawave remnawave
|
||||
```
|
||||
|
||||
После входа в `Rescue CLI` выберите пункт `Reset superadmin`.
|
||||
|
||||
### Экстренное включение входа по паролю
|
||||
|
||||
Если вы отключили метод входа "Пароль", но в дальнейшем потеряли доступ к одному из других методов входа – вы можете включить метод входа "Пароль" с помощью `Rescue CLI`
|
||||
|
||||
```bash
|
||||
docker exec -it remnawave remnawave
|
||||
```
|
||||
|
||||
После входа в `Rescue CLI` выберите пункт `Enable password authentication `.
|
||||
35
_panel-docs/help-articles/ru/AUTH_METHODS_POCKETID.md
Normal file
@@ -0,0 +1,35 @@
|
||||
## OAuth2: PocketID
|
||||
|
||||
### Создание OIDC Client
|
||||
|
||||
Зайдите в админ-панель PocketID и перейдите в раздел `Settings` → `OIDC Clients` → `Add OIDC Client`
|
||||
|
||||
```
|
||||
# Замените YOUR_PANEL_DOMAIN на ваш адрес панели Remnawave
|
||||
https://YOUR_PANEL_DOMAIN/oauth2/callback/pocketid
|
||||
```
|
||||
|
||||
### Настройки OAuth2 в Remnawave
|
||||
|
||||
После создания OAuth2 приложения – скопируйте `Client ID` и `Client Secret`. Вставьте эти данные в соответствующем разделе. А чуть ниже введите список email-адресов для которых будет разрешен вход.
|
||||
|
||||
В поле `Домен` (`Plain Domain`) введите доменный адрес, на котором у вас расположен PocketID. Достаточно ввести просто доменное имя – без пути и https://, например: `pocketid.your-domain.com`
|
||||
|
||||
### Custom Claims (v2.4.0+)
|
||||
|
||||
Remnawave так же поддерживает авторизацию через добавление Custom Claims.
|
||||
При использовании этого метода, массив email-адресов можно не указывать.
|
||||
|
||||
Ключ
|
||||
|
||||
```
|
||||
remnawaveAccess
|
||||
```
|
||||
|
||||
Значение
|
||||
|
||||
```
|
||||
true
|
||||
```
|
||||
|
||||
Соотвественно, если пользователь имеет этот ключ (`remnawaveAccess: true`) в токене, то он будет авторизован.
|
||||
43
_panel-docs/help-articles/ru/AUTH_METHODS_TELEGRAM.md
Normal file
@@ -0,0 +1,43 @@
|
||||
## Telegram OAuth2
|
||||
|
||||
> Этот гайд актуален для версии **2.7.0** и выше.
|
||||
|
||||
Для настройки функции "Вход через Telegram" вам необходим Telegram-бот, так же необходимо дополнительно настроить бота, чтобы функция работала корректно.
|
||||
|
||||
### Настройка бота
|
||||
|
||||
1. Откройте @BotFather (https://t.me/botfather)
|
||||
2. Откройте MiniApp кнопкой "Open"
|
||||
3. Выберите вашего бота и нажмите `Bot Settings`
|
||||
4. Если в разделе `Web Login` уже указан домен — удалите его.
|
||||
5. Нажмите кнопку Switch to OpenID Connect Login.
|
||||
`Если такой кнопки нет, после удаления домена вернитесь на пункт меню назад и повторите действия с шага 3`
|
||||
6. Нажмите Add an Allowed URL.
|
||||
Укажите следующие значения:
|
||||
|
||||
- Trusted Origins: https://panel.domain.com
|
||||
- Redirect URIs: https://panel.domain.com/oauth2/callback/telegram
|
||||
|
||||
### Настройка доступа
|
||||
|
||||
После заполнения `Client ID`, `Client Secret` и `Frontend Domain`, вам необходимо указать список ID – администраторов, для которых будет доступен вход.
|
||||
|
||||
1. С нужного аккаунта запустите бота – https://t.me/Get_myidrobot
|
||||
2. В ответ бот пришлет вам ваш ID, введите его в соответсвующее поле.
|
||||
|
||||
---
|
||||
|
||||
### Решение известных ошибок
|
||||
|
||||
###### Разного рода защиты установленные поверх панели (наподобие куки, и тд.) могут работать некорректно с `Telegram OAuth2`.
|
||||
|
||||
Используйте путь /oauth2/ в своих реверс прокси для решения этой проблемы
|
||||
|
||||
###### Ошибка: BOT_DOMAIN_INVALID
|
||||
|
||||
Эта ошибка возникает из-за неправильной настройки домена бота – изучите пункт "Настройка бота" (выше). При необходимости выполните повторно этот пункт шаг за шагом.
|
||||
|
||||
###### Ошибка: не приходит код подтверждения от Telegram при логине
|
||||
|
||||
К сожалению, со стороны Remnawave эту проблему не решить. Попробуйте использовать бота, который был создан давно или использовать другой браузер.
|
||||
Так же, как вариант вы можете попробовать залогиниться на одном из "официальных" ресурсорв – например https://fragment.com. Так как сессия Telegram в рамках браузера будет общей – вы можете попробовать залогиниться в панель.
|
||||
20
_panel-docs/help-articles/ru/AUTH_METHODS_YANDEX.md
Normal file
@@ -0,0 +1,20 @@
|
||||
## OAuth2: Yandex
|
||||
|
||||
Метод аутентификации через Яндекс не рекомендуется к использованию.
|
||||
|
||||
### Создание OAuth приложения
|
||||
|
||||
Вам необходимо создать Oauth-приложение в Яндексе.
|
||||
|
||||
Перейдите по ссылке для создания приложения: https://oauth.yandex.com/client/new
|
||||
|
||||
На втором шаге создания приложения выберите опцию «Веб-приложение» и впишите `Callback URL`
|
||||
|
||||
```
|
||||
# Замените YOUR_PANEL_DOMAIN на ваш адрес панели Remnawave
|
||||
https://YOUR_PANEL_DOMAIN/oauth2/callback/yandex
|
||||
```
|
||||
|
||||
Не забудьте заменить `YOUR_PANEL_DOMAIN` на корректный адрес панели.
|
||||
|
||||
На третьем шаге создания – обязательно поставьте галочку возле пункта `Access to email address` (`Доступ к email адресу`), никаких других разрешений не требуется.
|
||||
31
_panel-docs/help-articles/ru/EDITOR_TEMPLATES_XRAY_JSON.md
Normal file
@@ -0,0 +1,31 @@
|
||||
## Формат подписки Xray JSON
|
||||
|
||||
Формат Xray JSON обеспечивает поддержку подписок в формате JSON для совместимых клиентов. Просто добавьте `/json` в конец URL вашей подписки, чтобы включить этот формат.
|
||||
|
||||
### Поддерживаемые приложения
|
||||
|
||||
- **v2rayNG** — версия 1.8.29 или выше
|
||||
- **V2rayN** — версия 6.40 или выше
|
||||
- **Streisand** — все версии
|
||||
- **Happ** — все версии
|
||||
- **V2Box** — все версии
|
||||
- **ktor-client** — все версии
|
||||
|
||||
### Инструкции по использованию
|
||||
|
||||
**Шаг 1:** Измените URL вашей подписки
|
||||
|
||||
Добавьте `/json` в конец вашей ссылки на подписку:
|
||||
`https://<сервер>/api/sub/xxxx/json`
|
||||
|
||||
**Шаг 2:** Проверьте совместимость
|
||||
|
||||
Убедитесь, что ваше клиентское приложение соответствует минимальным требованиям к версии, перечисленным выше.
|
||||
|
||||
**Или:** Включите JSON на базовом пути
|
||||
|
||||
Включите опцию "Обслуживать JSON на базовом пути подписки" в настройках подписки. Это позволит обслуживать подписку JSON на базовом пути подписки (без необходимости добавлять /json).
|
||||
|
||||
### Резервное поведение
|
||||
|
||||
Для клиентов, которые не поддерживают формат JSON (таких как клиенты на основе Base64 или Mihomo), подписка автоматически вернется к стандартному формату, совместимому с вашим клиентом.
|
||||
107
_panel-docs/help-articles/ru/PAGE_CONFIG_PROFILES.md
Normal file
@@ -0,0 +1,107 @@
|
||||
## Профили
|
||||
|
||||
Профиль, в контексте Remnawave, представляет из себя полную серверную конфигурацию ядра [Xray](https://xtls.github.io/ru/config/).
|
||||
|
||||
В этой конфигурации вы прописываете _инбаунды_, к которым потом будут подключаться ваши пользователи.
|
||||
|
||||
**Здесь не будут описаны детали настройки конфигурации Xray, так как это тема для самостоятельного изучения – воспользуйтесь официальной документацией [Xray](https://xtls.github.io/ru/config/) для изучения всех возможностей ядра.**
|
||||
|
||||
При создании нового профиля, профиль по умолчанию создается с одним _инбаундом_ типа **Shadowsocks**. После того, как профиль создан – вы можете изменить этот или добавить новый _инбаунд_.
|
||||
|
||||
_Совет: чтобы добавить новый инбаунд, например с протоколом **VLESS** – просто добавьте еще один объект внутрь массива `inbounds:[]`._
|
||||
|
||||
На данный момент, Remnawave поддерживает такие протоколы как: `VLESS`, `Trojan`, `Shadowsocks` (`chacha20-ietf-poly1305`, `2022-blake3-aes-256-gcm`, `aes-128-gcm`, `aes-256-gcm`), `Hysteria2` (только для клиентского Xray-Json). И так же следующие транспорты: `RAW (TCP)`, `XHTTP`, `Websocket`, `HTTPUpgrade`, `gRPC`, `KCP`.
|
||||
|
||||
Важно отметить, что Remnawave так же поддерживает протоколы: `Tunnel`, `mixed(socks)`, `wireguard`,`http` – однако панель будет полностью их игнорировать и менеджмент пользователей для этих протоколов будет недоступен. Эти _инбаунды_ будет переданы в Xray в таком виде, в каком вы их укажите.
|
||||
|
||||
Для основных протоколов (`VLESS`, `Trojan`, `Shadowsocks`) Remnawave будет заниматься управлением списка пользователей, которые будут внутри серверной конфигурации. С вашей стороны никаких дополнительных действий не требуется.
|
||||
|
||||
---
|
||||
|
||||
### Список профилей
|
||||
|
||||
В общем списке профилей доступна краткая сводка по каждому созданному профилю. Под названием профиля вы можете увидеть количество активных _инбаундов_ внутри него, а так же количество активных **нод**, на которых этот профиль активен. Оба значка – кликабельны, при нажатии на них откроются соотвествующие разделы.
|
||||
|
||||
При клике на _инбаунды_ – будет открыт список _инбаундов_, и так же для каждого инбаунда будет написано, на скольких внутренних сквада этот _инбаунд_ активирован.
|
||||
При клике на _ноды_ – будет открыт список _нод_, который этот конкретный профиль активен.
|
||||
|
||||
В меню дополнительных действий (стрелочка вниз) доступны опции по быстрому просмотру конфигурации, просмотр конфигурации со сниппетами, а так же остальные сервисные опции.
|
||||
|
||||
---
|
||||
|
||||
### Редактор конфигурации
|
||||
|
||||
В редакторе конфигурации доступен полноценный JSON редактор, с проверкой синтаксиса, так же при наведении на некоторые объекты будет доступна всплывающая подсказка с информацией из документации Xray.
|
||||
|
||||
При любых изменениях, вся конфигурация немедленно валидируется путем запуска облегченной версии ядра. Такая валидация поможет не допускать банальных ошибок и опечаток.
|
||||
|
||||
В дополнительном меню (в самом низу, кнопка с тремя полосками) доступны дополнительные опции. Опустим базовые вещи: скопировать все, выделить все и так далее – эти опции понятны и без объяснения.
|
||||
|
||||
Пункт "**Скачать с Github**" откроет дополнительное меню, в котором вы можете скачать примеры конфигурации от пользователей. **Эти примеры не представляют из себя готовую конфигурацию, а лишь являются примерами – имейте это в виду.**
|
||||
|
||||
Пункт "**Сгенерировать ключи**" позволит прямо в браузере быстро и удобно сгенерировать необходимые пары ключей – например, в случае с `Reality` вам гарантировано будет нужен `privateKey`, который как раз можно сгенерировать в этом меню. Там же доступны и другие варианты генерации, которые пригодятся для `Vless Encryption` - `ML-DSA65` и `ML-KEM768`.
|
||||
|
||||
---
|
||||
|
||||
### Сниппеты
|
||||
|
||||
Когда профилей (конфигураций) становится много – бывает довольно сложно быстро поменять какие мелочи, которые присутствуют во всех профилях, но отличаются в мелочах.
|
||||
|
||||
Например, у вас есть несколько профилей – допустим 10 штук, в каждом из 10 штук раздел роутинга у вас одинаковый и вы бы хотели быстро и удобно заменить правила во всех профилях сразу. С функционалом сниппетов вам будет достаточно изменить "правило" или "правила" в одном месте, а потом они автоматически подтянутся в профили.
|
||||
|
||||
На данный момент вы можете заранее предопределить элементы массивов для таких объектов как `outbounds` и `rules`. После создания сниппета он будет доступен в одном из этих объектов.
|
||||
|
||||
```
|
||||
{
|
||||
"outbounds": [
|
||||
{
|
||||
"snippet": "snippet-name"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Дополнительная информация по ним доступна при нажатии на знак вопроса в меню сниппетов.
|
||||
|
||||
### Контроль flow (VLESS)
|
||||
|
||||
_Эта функция доступна только на версии 2.3.0 и выше._
|
||||
|
||||
По умолчанию, Remnawave автоматически добавляет flow для следующих конфигураций: VLESS+TLS/REALITY+RAW/TCP.
|
||||
|
||||
Если вы хотите переопределить это поведение, добавьте объект `flow` в объект `settings`.
|
||||
|
||||
```json
|
||||
"settings": {
|
||||
"flow": "",
|
||||
"clients": [],
|
||||
"decryption": "none"
|
||||
},
|
||||
```
|
||||
|
||||
Доступные значения для `flow`:
|
||||
|
||||
- `xtls-rprx-vision`
|
||||
- `""`
|
||||
|
||||
### Kcp with FinalMask
|
||||
|
||||
_Эта функция доступна только на версии 2.7.0 и выше._
|
||||
|
||||
В некоторых ситуациях требуется передавать кастомный MTU (в объекте `kcpSettings`) при использовании FinalMask. К сожалению, в конфигурации Xray нет четкого разделения на клиентский и серверный MTU.
|
||||
|
||||
```json
|
||||
{
|
||||
"mtu": 1350
|
||||
}
|
||||
```
|
||||
|
||||
Так как Remnawave необходимо генерировать клиентскую сторону – мы добавили кастомное поле, которого не существует в оригинальной конфигурации Xray.
|
||||
|
||||
```json
|
||||
{
|
||||
"clientMtu": 70
|
||||
}
|
||||
```
|
||||
|
||||
Параметр `clientMtu` (при его наличии) будет преобразован в `mtu` в клиентской стороне. Таким образом, вы можете передать кастомный MTU в клиентской стороне.
|
||||
43
_panel-docs/help-articles/ru/PAGE_EXTERNAL_SQUADS.md
Normal file
@@ -0,0 +1,43 @@
|
||||
## Внешние сквады
|
||||
|
||||
С помощью внешних сквадов вы можете переопределить некоторые настройки или шаблоны, которые получают пользователи при запросе подписки. _У одного пользователя не может быть больше одного активного внешнего сквада._
|
||||
|
||||
Например, для разных групп пользователей вы можете задать разный роутинг (для Happ, v2rayTUN), разный роутинг может быть в том числе внутри шаблонов.
|
||||
|
||||
С помощью дополнительного меню вы можете быстро назначить внешний сквад всем пользователям (или наоборот убрать всех пользователей из внешнего сквада).
|
||||
|
||||
Если у пользователя не выбран внешний сквад – будут использованы глобальные настройки из раздела «**Подписка**», а так же шаблон клиентского конфига «**Default**».
|
||||
|
||||
---
|
||||
|
||||
Плавно перейдем к рассмотрению настроек, которые доступны в карточке внешнего сквада.
|
||||
|
||||
### Переопределение шаблонов
|
||||
|
||||
Когда пользователь запрашивает подписку – в зависимости от клиентского приложения из которого пришел запрос, пользователь может получить разные шаблоны. Например, если приложение, которое работает на ядре Mihomo – Remnawave увидит это и выдаст **Default** шаблон типа **Mihomo**. (Управлять шаблонами вы можете в соотвествующем разделе).
|
||||
|
||||
Внутри Remnawave вы можете создавать бесконечное множество шаблонов для каждого типа (Mihomo, Stash, Xray Json, Singbox, Clash), но по умолчанию всегда будет отдаваться **Default** шаблон соотвествующего типа.
|
||||
|
||||
**Чтобы переопределить это поведение как раз и существует эта настройка внутри внешнего сквада.**
|
||||
|
||||
Допустим, для определенного внешнего сквада мы хотим использовать _Custom Template_, который принадлежит к типу **Mihomo**, в таком случае мы выбираем этот шаблон в соответствующем разделе и сохраняем изменения. Если запрос придет от пользователя, который состоит в этом внешнем скваде – вместо _Default_ шаблона он получит _Custom Template_.
|
||||
|
||||
Если оставить поле переопределения пустым – пользователь, который находится в этом скваде получит _Default_ шаблон.
|
||||
|
||||
_Обратите внимание, переопределение шаблона в разделе «Правила ответов» имеет более высокий приоритет, чем переопределение в этом разделе._
|
||||
|
||||
### Настройки (подписки)
|
||||
|
||||
В этом разделе переопределяются общие настройки, которые находятся в разделе «Подписка» → «Настройки». Соотвественно, с помощью переопределения настроек в рамках сквада вы можете переопределить многие параметры сразу для целой группы пользователей.
|
||||
|
||||
Имейте в виду, если любой из параметров явно переопределен (в том числе пустое значение) – он будет переопределен. Только удаление переопределения (значек корзины) отменит переопределение.
|
||||
|
||||
К примеру, в общих настройках заголовок профиля у меня указан как «Remnawave», но для 10-ти пользователей я хочу переопределить его, например на «Remnawave v.2.x», в таком случае в этом разделе я переопределяю этот параметр, а потом нужным 10-ти пользователям назначаю этот внешений сквад.
|
||||
|
||||
### Хосты
|
||||
|
||||
Основываясь на логике из предыдущего пункта – в этом разделе можно полностью переопределить некоторые параметры, которые вы могли заметить в карточке каждого созданного вами **хоста**.
|
||||
|
||||
**Переопределенные здесь значения будут применены ко всем хостам, которые получает пользователь в подписке.**
|
||||
|
||||
Например, с помощью переопределение `vlessRouteId` мы можем назначить определенное значение и таким образом «_роутить_» целую группу пользователей (тех, которые будут находиться в этом скваде). Само собой, вторая половина настроек такого роутинга находится в серверной конфигурации – профиля.
|
||||
67
_panel-docs/help-articles/ru/PAGE_HOSTS.md
Normal file
@@ -0,0 +1,67 @@
|
||||
## Хосты
|
||||
|
||||
Кратко говоря, хосты это клиентская репрезентация вашей серверной конфигурации. Если на сервере для успешного подключения необходимо **инбаунд**, то на клиентской стороне пользователю необходим **хост**.
|
||||
|
||||
Группа хостов (или можно сказать _список_), представляет из себя подписку. Подписка – это ссылка, после добавления такой ссылки в клиентское приложение перед пользователем появляется список хостов (серверов, если угодно). И далее пользователь уже вправе выбирать любой из них.
|
||||
|
||||
Важно заметить, что **хост** является в первую очередь лишь клиентской интерпретация вашей серверной части. Например, если пользователь получил подписку (список хостов у него уже на руках), а вы отключите этот хост – пользователь по прежнему **сможет** подключиться к серверу, на который направлен этот хост. Но при обновлении подписки – этого хоста у него уже не будет.
|
||||
|
||||
Так как хост привязывается напрямую к инбаунду (который находится в профиле) – хост наследует большинство настроек из него, однако в некоторых случаях бывает полезно переопределить или дополнить эти настройки – для этого существует раздел **расширенных** настроек.
|
||||
|
||||
---
|
||||
|
||||
При создании нового хоста или редактировании существующего, перед вами доступно два раздела: **Основные** и **Расширенные** (настройки).
|
||||
|
||||
### Основные
|
||||
|
||||
#### Примечание
|
||||
|
||||
В этом пункте вы определяете как данный хост будет отображаться в клиентском приложение. Обычно здесь пишут название страны, к которой будет подключаться пользователь.
|
||||
|
||||
_Совет: чтобы в клиентском приложении отображался флаг страны – добавьте эмоджи в самое начало примечания._
|
||||
|
||||
#### Выбор инбаунда (и профиля)
|
||||
|
||||
Как уже упоминалось выше – хост это лишь клиентская репрезентация вашей серверной конфигурации, поэтому и обязательным требованием к созданию хоста является выбор инбаунда. В зависимости от количества инбаундов, нод и профилей выберите соотвествующий инбаунд в меню выбора.
|
||||
|
||||
#### Адрес и порт
|
||||
|
||||
Адресом является домен или IP-адрес, в большинстве случаев здесь необходимо прописать адрес или домен сервера, к которому будет подключаться пользователь. Порт – обычно соответствует порту **инбаунда**, _в некоторых случаях может отличаться._
|
||||
|
||||
_В адрес можно так же вписать несколько доменных имен – например: `node-1.com,node-2.com,node-3.com`. Может возникнуть мысль, что с помощью этого в теории можно производить некоторую балансировку, но важно заметить – пользователь при запросе подписки получит лишь один из этих адресов (что конкретно он получит определяется случайно и не привязано к какому-либо логике балансировке). Следовательно – до тех пор, пока пользователь не обновит подписку в клиентском приложении (или если не сработает автообновление) – адрес у пользователя не изменится._
|
||||
|
||||
#### Тег и ноды
|
||||
|
||||
Эти параметры не видны конечному пользователю, они больше нужны администратору панели (вам), чтобы в будущем было проще ориентироваться в созданных хостах, если их будет много.
|
||||
В частности, выбор ноды в этом пункте не играет функциональной роли – **это только визуальная привязка для более простого ориентирования в будущем.**
|
||||
|
||||
---
|
||||
|
||||
### Расширенные
|
||||
|
||||
**В большинстве случаев вам не нужно редактировать ничего из этого раздела, если вы явно не понимаете для каких целей это делаете. Некорректное изменение некоторых параметров может привести к тому, что ваше подключение будет не работать. Отнеситесь к редактированию каждого пункта со всей серьезности и всегда проверяйте дважды сверяйте настройки перед применением изменений.**
|
||||
|
||||
В этом разделе мы не будем делать проходить по каждому пункту – сконцентрируемся на основных пунктах.
|
||||
|
||||
#### SNI (ServerNames)
|
||||
|
||||
В некоторых случаях бывает необходимо переопределить настройки объекта `serverNames` (которые определяются внутри инбаунда в профиле) для конкретного хоста.
|
||||
|
||||
Имейте в виду, `serverNames` простым языком является _паролем_, по которому, например, **Reality** определяет **валидность** соединения. Если вы в этом пункте укажете **SNI**, например `example.com` и при этом внутри инбаунда `serverNames` выглядят вот так:
|
||||
|
||||
```json
|
||||
"serverNames": [
|
||||
"example1.com",
|
||||
"example2.com"
|
||||
]
|
||||
```
|
||||
|
||||
Такое соединение работать не будет, так как `example.com` не находится в списке разрешенных `SNI`.
|
||||
|
||||
#### Переопределить SNI из адреса
|
||||
|
||||
По умолчанию, Remnawave берет первый объект из массива `serverNames` (инбаунда) чтобы добавить SNI в клиентский хост. Если вы включите этот параметр – Remnawave возьмет адрес (который вы указали в разделе **Основные**) и передаст его клиенту.
|
||||
|
||||
Из прочих пунктом в этом разделе так же можно выделить пункт `vlessRouteId`, который является небольшим слоем абстракции над Xray Core и предоставляем вам простой способ воспользоваться функционалом `vlessRoute`, который предоставляет Xray. <a href="https://xtls.github.io/ru/config/routing.html#ruleobject">Ознакомиться подробнее с правилами роутинга.</a>
|
||||
|
||||
---
|
||||
21
_panel-docs/help-articles/ru/PAGE_INTERNAL_SQUADS.md
Normal file
@@ -0,0 +1,21 @@
|
||||
## Внутренние сквады
|
||||
|
||||
Основная цель внутренних сквадов – это **разграничение** доступа пользователей.
|
||||
|
||||
Внутренние сквады напрямую связаны с **профилями** и их **инбаундами**. Им можно назначить сколько угодно активных инбаундов (которые находятся внутри профилей). А так как профили и их инбаунды напрямую связаны с нодами – с помощью внутреннего сквада мы можем тонко контролировать какие пользователи или группы пользователей могут иметь доступ к нодам.
|
||||
|
||||
---
|
||||
|
||||
В карточке каждого сквада (в общем списке) вы можете заметить количество активных инбаундов, а так же количество участников этого сквада (пользователей, которые состоят в нем).
|
||||
|
||||
При нажатии на кнопку дополнительных действий (в карточке сквада) вы можете так же быстро добавить или удалить всех пользователей. Если вам требуется назначить сквад каким-то _определенным_ пользователям – вы можете это сделать в разделе **«Пользователи»**.
|
||||
|
||||
Менеджмент пользователей и нод, которые могут быть им доступны иногда бывает очень запутанным – воспользуйтесь кнопкой **«Доступные ноды»**, чтобы быстро посмотреть какие ноды доступны этому скваду. Напомню, что при создании или изменнии **ноды** мы так же в ней выбираем какой **профиль** будет использоваться и какие **инбаунды** из него будут активны на ноде. И так как внутри сквада мы тоже выбираем **инбаунды**, поэтому мы можем с помощью связей определить конкретные ноды, к которым у этого сквада (следовательно и его участников) будет доступ.
|
||||
|
||||
---
|
||||
|
||||
Для примера, у нас есть две группы пользователей: **бесплатные** и **платные**. И мы хотим, что бы **бесплатные** пользователи имели доступ к _группе серверов #1_, а платные имели доступ и к _группе серверов #1_, а так же дополнительно к _группе серверов #2_.
|
||||
|
||||
Для этой цели мы создадим два сквада: **Free** и **Premium**, внутри каждого из них выбираем соответствующие инбаунды.
|
||||
|
||||
И допустим, что мы уже создаем пользователя – в таком случае если перед нами бесплатный пользователь – мы просто активируем для него внутренний сквад **Free**. А когда перед нами будет платный пользователь – активируем оба сквада – **Free** и **Premium** (если нужно, чтобы у пользователя был доступ ко всем нодам/инбаундам). Но мы так же можем для платного пользователя активировать только один сквад – **Premium**, в таком случае доступа к нодам/инбаундам из группы **Free** у пользователя не будет.
|
||||
115
_panel-docs/help-articles/zh/AUTH_METHODS_GENERIC.md
Normal file
@@ -0,0 +1,115 @@
|
||||
# Generic OAuth2 身份验证
|
||||
|
||||
Generic OAuth2 允许您将任何兼容 OAuth2 的身份提供商连接到 Remnawave。当您想使用没有专门集成的提供商时(如 Authentik、Authelia、Zitadel、Google、Microsoft 等),这非常有用。
|
||||
|
||||
## 前提条件
|
||||
|
||||
1. 兼容 OAuth2 的身份提供商
|
||||
2. 创建 OAuth2 客户端/应用程序的管理员权限
|
||||
3. 提供商必须支持令牌中的 `email` 声明
|
||||
|
||||
## 配置步骤
|
||||
|
||||
### 1. 在您的提供商中创建 OAuth2 应用程序
|
||||
|
||||
具体步骤因提供商而异,但通常您需要:
|
||||
|
||||
1. 登录到您的身份提供商管理控制台
|
||||
2. 创建新的 OAuth2/OIDC 应用程序
|
||||
3. 配置:
|
||||
- **应用程序类型**:Web Application
|
||||
- **授权类型**:Authorization Code
|
||||
- **重定向 URI**:`https://your-panel-domain.com/oauth2/callback/generic`
|
||||
4. 记下 **Client ID** 和 **Client Secret**
|
||||
5. 找到提供商的 **Authorization URL** 和 **Token URL**(通常在文档或 well-known 端点中)
|
||||
|
||||
### 2. 查找提供商 URL
|
||||
|
||||
大多数提供商都记录了这些端点。常见模式:
|
||||
|
||||
| 提供商 | Authorization URL | Token URL |
|
||||
| --------- | ------------------------------------------------------------------ | -------------------------------------------------------------- |
|
||||
| Google | `https://accounts.google.com/o/oauth2/v2/auth` | `https://oauth2.googleapis.com/token` |
|
||||
| Microsoft | `https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize` | `https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token` |
|
||||
| Authentik | `https://your-authentik.com/application/o/authorize/` | `https://your-authentik.com/application/o/token/` |
|
||||
| Authelia | `https://your-authelia.com/api/oidc/authorization` | `https://your-authelia.com/api/oidc/token` |
|
||||
| Zitadel | `https://your-zitadel.com/oauth/v2/authorize` | `https://your-zitadel.com/oauth/v2/token` |
|
||||
|
||||
### 3. PKCE 支持
|
||||
|
||||
**PKCE(Proof Key for Code Exchange)** 为 OAuth2 流程添加了额外的安全层。在以下情况下启用此选项:
|
||||
|
||||
- 您的提供商支持 PKCE(大多数现代提供商都支持)
|
||||
- 您希望增强对授权码拦截攻击的保护
|
||||
- 您的提供商要求公共客户端使用 PKCE
|
||||
|
||||
> **建议**:如果您的提供商支持 PKCE,请启用它。
|
||||
|
||||
## Remnawave 配置
|
||||
|
||||
| 字段 | 描述 |
|
||||
| --------------------- | -------------------------------------------------------------------- |
|
||||
| **Client ID** | 来自您的 OAuth2 提供商的客户端/应用程序 ID |
|
||||
| **Client Secret** | 来自您的 OAuth2 提供商的客户端密钥 |
|
||||
| **Authorization URL** | OAuth2 授权端点 URL(例如 `https://provider.com/oauth2/authorize`) |
|
||||
| **Token URL** | OAuth2 令牌端点 URL(例如 `https://provider.com/oauth2/token`) |
|
||||
| **Frontend Domain** | 您的 Remnawave 面板域名,不带 `https://`(例如 `panel.example.com`) |
|
||||
| **With PKCE** | 启用 PKCE(Proof Key for Code Exchange)以增强安全性 |
|
||||
| **Allowed Emails** | 允许登录的电子邮件地址列表 |
|
||||
|
||||
## 访问控制
|
||||
|
||||
您可以使用**以下两种方法之一**(或两者同时使用)来控制访问:
|
||||
|
||||
### 选项 A:使用 Allowed Emails
|
||||
|
||||
在 Remnawave 设置中指定允许的电子邮件地址列表。只有电子邮件在此列表中的用户才能登录。
|
||||
|
||||
### 选项 B:使用自定义声明
|
||||
|
||||
如果 **Allowed Emails** 列表为空,Remnawave 将检查令牌中的自定义声明:
|
||||
|
||||
| 键 | 值 |
|
||||
| ----------------- | ------ |
|
||||
| `remnawaveAccess` | `true` |
|
||||
|
||||
如果用户的令牌包含 `remnawaveAccess: true`,他们将被授权。
|
||||
|
||||
> **注意**:您需要配置您的身份提供商以在令牌中包含此自定义声明。具体步骤因提供商而异——通常通过"映射器"、"声明"或"令牌自定义"设置完成。
|
||||
|
||||
## 故障排除
|
||||
|
||||
### "Invalid redirect URI"
|
||||
|
||||
验证您的提供商中的重定向 URI 完全匹配:`https://your-panel-domain.com/oauth2/callback/generic`
|
||||
|
||||
### "Invalid or missing email claim"
|
||||
|
||||
确保:
|
||||
|
||||
- 用户在您的提供商中设置了电子邮件地址
|
||||
- 已请求并授予 `email` 作用域
|
||||
- 您的提供商在令牌中包含 `email` 声明
|
||||
|
||||
### "State mismatch"
|
||||
|
||||
清除浏览器 Cookie 并重试。如果身份验证流程被中断,可能会发生这种情况。
|
||||
|
||||
### "Token exchange failed"
|
||||
|
||||
验证:
|
||||
|
||||
- **Token URL** 正确
|
||||
- **Client ID** 和 **Client Secret** 正确
|
||||
- 您的提供商的令牌端点可从 Remnawave 服务器访问
|
||||
|
||||
### "Access denied"
|
||||
|
||||
用户的电子邮件不在 **Allowed Emails** 列表中。添加他们的电子邮件地址以授予访问权限。
|
||||
|
||||
### PKCE 相关错误
|
||||
|
||||
如果您收到与 `code_verifier` 或 `code_challenge` 相关的错误:
|
||||
|
||||
- 如果您的提供商不支持 PKCE,请尝试禁用 **With PKCE**
|
||||
- 或者如果您的提供商要求使用 PKCE,请启用它
|
||||
21
_panel-docs/help-articles/zh/AUTH_METHODS_GITHUB.md
Normal file
@@ -0,0 +1,21 @@
|
||||
## OAuth2:GitHub
|
||||
|
||||
### 创建 OAuth 应用
|
||||
|
||||
首先,你需要创建一个 OAuth 应用。
|
||||
请通过以下链接创建应用:
|
||||
[https://github.com/settings/applications/new](https://github.com/settings/applications/new)
|
||||
|
||||
在 `Authorization callback URL` 字段中,填写你的面板地址。
|
||||
|
||||
```bash
|
||||
# 将 YOUR_PANEL_DOMAIN 替换为你的面板地址
|
||||
https://YOUR_PANEL_DOMAIN/oauth2/callback/github
|
||||
```
|
||||
|
||||
请务必将 `YOUR_PANEL_DOMAIN` 替换为正确的面板域名。
|
||||
|
||||
### Remnawave 中的 OAuth2 设置
|
||||
|
||||
创建 OAuth2 应用后,复制生成的 `Client ID` 和 `Client Secret`,并将它们填写到对应的配置项中。
|
||||
然后,在下方填写允许登录的邮箱地址列表。
|
||||
80
_panel-docs/help-articles/zh/AUTH_METHODS_KEYCLOAK.md
Normal file
@@ -0,0 +1,80 @@
|
||||
# Keycloak 身份验证
|
||||
|
||||
Keycloak 是一个开源的身份和访问管理解决方案,提供单点登录 (SSO) 功能。
|
||||
|
||||
## 先决条件
|
||||
|
||||
1. 运行中的 Keycloak 服务器
|
||||
2. 创建客户端的管理员权限
|
||||
|
||||
## 配置步骤
|
||||
|
||||
### 1. 在 Keycloak 中创建客户端
|
||||
|
||||
1. 登录 Keycloak 管理控制台
|
||||
2. 选择您的 realm(或创建新的)
|
||||
3. 进入 **Clients** → **Create client**
|
||||
4. 配置:
|
||||
- **Client ID**: `remnawave`(或您喜欢的名称)
|
||||
- **Client Protocol**: `openid-connect`
|
||||
- **Client authentication**: `ON`
|
||||
5. 设置 **Valid redirect URIs**: `https://your-panel-domain.com/oauth2/callback/keycloak`
|
||||
6. 设置 **Web Origins**: `https://your-panel-domain.com`
|
||||
7. 保存客户端
|
||||
|
||||
### 2. 获取客户端凭据
|
||||
|
||||
1. 进入 **Clients** → 您的客户端 → **Credentials** 选项卡
|
||||
2. 复制 **Client secret**
|
||||
|
||||
### 3. 配置访问控制
|
||||
|
||||
您可以使用**以下两种方法之一**(或同时使用)控制访问:
|
||||
|
||||
#### 选项 A:使用 Claim(推荐)
|
||||
|
||||
在令牌中添加自定义 claim `remnawaveAccess: true`:
|
||||
|
||||
1. 进入 **Clients** → 您的客户端 → **Client scopes** 选项卡
|
||||
2. 点击 `<your-client-id>-dedicated`
|
||||
3. 进入 **Mappers** 选项卡 → **Add mapper** → **By configuration**
|
||||
4. 选择 **Hardcoded claim**
|
||||
5. 配置:
|
||||
- **Name**: `remnawaveAccess`
|
||||
- **Token Claim Name**: `remnawaveAccess`
|
||||
- **Claim value**: `true`
|
||||
- **Claim JSON Type**: `boolean`
|
||||
- **Add to ID token**: `ON`
|
||||
- **Add to access token**: `ON`
|
||||
6. 保存
|
||||
|
||||
#### 选项 B:使用允许的邮箱列表
|
||||
|
||||
您可以在 Remnawave 设置中指定允许的邮箱地址列表,而不是配置 claim。只有邮箱在此列表中的用户才能登录。
|
||||
|
||||
## Remnawave 配置
|
||||
|
||||
| 字段 | 描述 |
|
||||
|------|------|
|
||||
| **Keycloak Domain** | Keycloak 服务器域名,不含 `https://`(例如 `keycloak.example.com`)|
|
||||
| **Frontend Domain** | Remnawave 面板域名,不含 `https://`(例如 `panel.example.com`)|
|
||||
| **Realm** | Keycloak realm 名称(例如 `master`)|
|
||||
| **Client ID** | 您创建的客户端 ID |
|
||||
| **Client Secret** | Credentials 选项卡中的客户端密钥 |
|
||||
| **Allowed Emails** | 允许登录的邮箱地址列表(使用 claim 时可选)|
|
||||
|
||||
## 故障排除
|
||||
|
||||
### "Email is not in the allowed list and remnawaveAccess claim is not present"
|
||||
请确保满足以下条件之一:
|
||||
- 用户通过 mapper 配置了 `remnawaveAccess: true` claim,或
|
||||
- 用户的邮箱已添加到 Remnawave 设置的 Allowed Emails 列表中
|
||||
|
||||
### "Invalid redirect URI"
|
||||
验证 Keycloak 中的重定向 URI 完全匹配:`https://your-panel-domain.com/oauth2/callback/keycloak`
|
||||
|
||||
### "State mismatch"
|
||||
清除浏览器 cookies 并重试。如果身份验证流程被中断,可能会发生这种情况。
|
||||
|
||||
### "Invalid or missing email claim"
|
||||
确保用户在 Keycloak 中设置了邮箱地址,并启用了 email scope。
|
||||
22
_panel-docs/help-articles/zh/AUTH_METHODS_PASSWORD.md
Normal file
@@ -0,0 +1,22 @@
|
||||
## 认证方式: 密码
|
||||
|
||||
### 修改或重置密码
|
||||
|
||||
使用 `Rescue CLI` 来重置或修改密码。
|
||||
|
||||
```bash
|
||||
docker exec -it remnawave remnawave
|
||||
```
|
||||
|
||||
进入 `Rescue CLI` 后,选择 `Reset superadmin` 选项。
|
||||
|
||||
### 启用紧急密码认证
|
||||
|
||||
如果你已禁用“Password”认证方式,但之后又无法通过其他认证方式登录,
|
||||
可以使用 `Rescue CLI` 重新启用“Password”认证方式。
|
||||
|
||||
```bash
|
||||
docker exec -it remnawave remnawave
|
||||
```
|
||||
|
||||
进入 `Rescue CLI` 后,选择 `Enable password authentication` 选项。
|
||||
40
_panel-docs/help-articles/zh/AUTH_METHODS_POCKETID.md
Normal file
@@ -0,0 +1,40 @@
|
||||
## OAuth2:PocketID
|
||||
|
||||
### 创建 OIDC 客户端
|
||||
|
||||
登录 PocketID 管理面板,并前往:
|
||||
`Settings` → `OIDC Clients` → `Add OIDC Client`
|
||||
|
||||
```
|
||||
# 将 YOUR_PANEL_DOMAIN 替换为你的 Remnawave 面板地址
|
||||
https://YOUR_PANEL_DOMAIN/oauth2/callback/pocketid
|
||||
```
|
||||
|
||||
### Remnawave 中的 OAuth2 设置
|
||||
|
||||
创建 OAuth2 应用后,复制生成的 `Client ID` 和 `Client Secret`,
|
||||
并将其填写到对应的配置项中。
|
||||
然后,在下方填写允许登录的邮箱地址列表。
|
||||
|
||||
在 `Plain Domain` 字段中,填写你的 PocketID 所在的域名。
|
||||
只需要填写域名本身,不要包含路径和 `https://`,例如:
|
||||
`pocketid.your-domain.com`
|
||||
|
||||
### 自定义声明(Custom Claims,v2.4.0+)
|
||||
|
||||
Remnawave 也支持通过自定义声明进行授权。
|
||||
使用此方式时,无需再配置允许的邮箱地址列表。
|
||||
|
||||
Key
|
||||
|
||||
```
|
||||
remnawaveAccess
|
||||
```
|
||||
|
||||
Value
|
||||
|
||||
```
|
||||
true
|
||||
```
|
||||
|
||||
只要用户的令牌中包含该键值对(`remnawaveAccess: true`),即可通过授权。
|
||||
43
_panel-docs/help-articles/zh/AUTH_METHODS_TELEGRAM.md
Normal file
@@ -0,0 +1,43 @@
|
||||
## Telegram OAuth2
|
||||
|
||||
> 本指南适用于 **2.7.0** 及以上版本。
|
||||
|
||||
要配置"通过 Telegram 登录"功能,您需要一个 Telegram 机器人。此外,还需要对机器人进行额外配置,功能才能正常工作。
|
||||
|
||||
### 机器人配置
|
||||
|
||||
1. 打开 @BotFather(https://t.me/botfather)
|
||||
2. 点击"Open"按钮打开 MiniApp
|
||||
3. 选择您的机器人,然后点击 `Bot Settings`
|
||||
4. 如果 `Web Login` 部分已经指定了域名 — 请先删除它。
|
||||
5. 点击 Switch to OpenID Connect Login 按钮。
|
||||
`如果没有看到此按钮,请在删除域名后返回上一级菜单,然后从步骤 3 重新操作`
|
||||
6. 点击 Add an Allowed URL。
|
||||
填写以下值:
|
||||
|
||||
- Trusted Origins: https://panel.domain.com
|
||||
- Redirect URIs: https://panel.domain.com/oauth2/callback/telegram
|
||||
|
||||
### 访问权限配置
|
||||
|
||||
在填写完 `Client ID`、`Client Secret` 和 `Frontend Domain` 后,您需要指定允许登录的管理员 ID 列表。
|
||||
|
||||
1. 使用对应账号打开机器人 – https://t.me/Get_myidrobot
|
||||
2. 机器人会返回您的用户 ID,将该 ID 填入对应的字段中。
|
||||
|
||||
---
|
||||
|
||||
### 已知错误解决方案
|
||||
|
||||
###### 安装在面板之上的各种保护措施(如 cookie 等)可能无法与 `Telegram OAuth2` 正常配合工作。
|
||||
|
||||
请在反向代理中使用 /oauth2/ 路径来解决此问题
|
||||
|
||||
###### 错误:BOT_DOMAIN_INVALID
|
||||
|
||||
此错误是由于机器人域名配置不正确导致的 — 请查看上方"机器人配置"部分。如有必要,请逐步重新执行配置。
|
||||
|
||||
###### 错误:登录时未收到 Telegram 验证码
|
||||
|
||||
很遗憾,此问题无法从 Remnawave 端解决。请尝试使用较早创建的机器人,或使用其他浏览器。
|
||||
此外,您也可以尝试先登录"官方"资源 — 例如 https://fragment.com。由于浏览器中的 Telegram 会话是共享的 — 之后您可以尝试登录面板。
|
||||
20
_panel-docs/help-articles/zh/AUTH_METHODS_YANDEX.md
Normal file
@@ -0,0 +1,20 @@
|
||||
## OAuth2:Yandex
|
||||
|
||||
不推荐使用 Yandex 的身份验证方式。
|
||||
|
||||
### 创建 OAuth 应用
|
||||
|
||||
你需要在 Yandex 中创建一个 OAuth 应用。
|
||||
|
||||
点击此链接创建应用: [https://oauth.yandex.com/client/new](https://oauth.yandex.com/client/new)
|
||||
|
||||
在创建应用的第二步中,选择 “Web application”(网页应用)选项,并填写 `Callback URL`
|
||||
|
||||
```
|
||||
# 将 YOUR_PANEL_DOMAIN 替换为你的 Remnawave 面板地址
|
||||
https://YOUR_PANEL_DOMAIN/oauth2/callback/yandex
|
||||
```
|
||||
|
||||
别忘了将 `YOUR_PANEL_DOMAIN` 替换为正确的面板域名。
|
||||
|
||||
在创建的第三步中 —— 请确保勾选 “Access to email address”(访问邮箱地址),不需要其他权限。
|
||||
32
_panel-docs/help-articles/zh/EDITOR_TEMPLATES_XRAY_JSON.md
Normal file
@@ -0,0 +1,32 @@
|
||||
## Xray JSON 订阅格式
|
||||
|
||||
Xray 的 JSON 格式为兼容客户端提供了原生的基于 JSON 的订阅支持。
|
||||
只需在订阅链接后添加 `/json` 即可启用此格式。
|
||||
|
||||
### 支持的客户端
|
||||
|
||||
- **v2rayNG** — 版本 1.8.29 或更高
|
||||
- **V2rayN** — 版本 6.40 或更高
|
||||
- **Streisand** — 所有版本
|
||||
- **Happ** — 所有版本
|
||||
- **V2Box** — 所有版本
|
||||
- **ktor-client** — 所有版本
|
||||
|
||||
### 使用说明
|
||||
|
||||
**步骤 1:** 修改订阅链接
|
||||
|
||||
在你的订阅链接末尾添加 `/json` :
|
||||
`https://<server>/api/sub/xxxx/json`
|
||||
|
||||
**步骤 2:** 检查兼容性
|
||||
|
||||
确保你的客户端版本满足上方列出的最低要求。
|
||||
|
||||
**可选方式:** 在基础路径启用 JSON
|
||||
|
||||
在订阅设置中启用 "在基础订阅路径提供 JSON" 选项。 启用后,系统会直接在基础路径提供 JSON 订阅 (无需额外添加 /json).
|
||||
|
||||
### 回退机制
|
||||
|
||||
对于不支持 JSON 格式的客户端(例如使用 Base64 或 Mihomo 协议的客户端),系统会自动回退到与客户端兼容的标准订阅格式。
|
||||
111
_panel-docs/help-articles/zh/PAGE_CONFIG_PROFILES.md
Normal file
@@ -0,0 +1,111 @@
|
||||
## 配置文件(Config Profiles)
|
||||
|
||||
在 Remnawave 的配套设置中,配置文件(Config Profile) 代表一份完整的服务器配置, 用于 [Xray](https://xtls.github.io/en/config/) 内核.
|
||||
|
||||
在此配置中,你可以定义用户将来要连接的 _入站(inbounds)_ 。
|
||||
|
||||
**此处不会详细介绍 Xray 配置的具体结构和语法,因为这是一个需要独立学习的主题。 - 如需了解核心的完整功能,请参阅官方 [Xray文档](https://xtls.github.io/en/config/) 。**
|
||||
|
||||
当你创建一个新的配置文件时,系统会默认生成一个类型为**Shadowsocks**的 _入站(inbounds)_。 创建完成后,你可以修改该入站,或添加新的 _入站(inbounds)_。
|
||||
|
||||
_如果你想添加一个新的入站(例如使用 **VLESS** 协议),只需在 `inbounds:[]` 数组中添加一个新的对象即可。_
|
||||
|
||||
目前,Remnawave 支持以下协议: `VLESS`, `Trojan`, `Shadowsocks` (`chacha20-ietf-poly1305`, `2022-blake3-aes-256-gcm`, `aes-128-gcm`, `aes-256-gcm`), `Hysteria2`(仅用于客户端 Xray-Json 生成)。 并支持以下传输方式: `RAW (TCP)`, `XHTTP`, `Websocket`, `HTTPUpgrade`, `gRPC`, `KCP`.
|
||||
|
||||
需要注意的是,Remnawave 也支持以下协议: `Tunnel`, `mixed(socks)`, `wireguard`, `http` - 但面板不会对它们进行任何处理,这些协议的用户管理功能将不可用。 此类 _入站(inbounds)_ 将按原样传递给 Xray,不会被修改。
|
||||
|
||||
对于主要协议 (`VLESS`, `Trojan`, `Shadowsocks`), Remnawave 会自动管理服务器配置中的用户列表,无需额外手动操作。
|
||||
|
||||
---
|
||||
|
||||
### 配置文件列表(Config Profiles List)
|
||||
|
||||
在配置文件列表中,每个配置文件都会显示简要概览。 在配置文件名称下方,你可以看到其中活动的 _入站(inbounds)_ 数量, 以及当前使用该配置文件的 **节点(nodes)** 数量。 这两个图标均可点击,点击后会打开对应的详细页面。
|
||||
|
||||
点击 _入站(inbounds)_ - 会显示该配置文件中的 _入站_ 列表,并显示每个 _入站_ 在多少个内部分组中被激活。
|
||||
点击 _节点(nodes)_ - 会显示当前使用此配置文件的所有 _节点_ 列表。
|
||||
|
||||
在“更多操作”菜单(向下箭头)中,你还可以快速查看配置文件、查看带有代码片段(snippets)的配置文件,以及其他服务相关选项。
|
||||
|
||||
---
|
||||
|
||||
### 配置文件编辑器(Config Profile Editor)
|
||||
|
||||
配置文件编辑器提供了一个功能完整的 JSON 编辑器,支持语法高亮和结构检查。当鼠标悬停在某些对象上时,还会显示来自 Xray 文档的提示信息。
|
||||
|
||||
每当进行更改时,系统会立即运行轻量级的核心实例来验证整个配置。这种实时验证可以有效防止低级错误或拼写问题。
|
||||
|
||||
在底部的附加菜单(带三条横线的按钮)中,你可以找到更多选项。像“全选”、“复制全部”等基础功能就不赘述了。
|
||||
|
||||
"**从 Github 加载**" 选项会打开一个菜单,允许你下载其他用户分享的配置示例。 **这些示例仅供参考,并非可直接使用的配置。**
|
||||
|
||||
"**生成密钥**" 功能可以直接在浏览器中生成所需的密钥对 - 例如,在使用 `Reality` 时, 你需要生成一个 `privateKey`,可以在此处完成。 此外,还支持生成适用于 `Vless Encryption` 的 `ML-DSA65` 和 `ML-KEM768`.
|
||||
|
||||
---
|
||||
|
||||
### 代码片段(Snippets)
|
||||
|
||||
当你拥有多个配置文件时,若需要修改一些在所有配置中都存在但略有不同的细节,手动逐一修改将非常麻烦。
|
||||
|
||||
例如,你有 10 个配置文件,它们的路由规则基本一致,只是细节不同。
|
||||
此时可以使用 Snippets 功能——你只需在一个地方修改“规则(rule)”或“规则集(rules)”,
|
||||
系统就会自动将这些更改同步到所有配置文件中。
|
||||
|
||||
目前,你可以为以下对象预定义数组元素: `outbounds` 和 `rules`。 创建片段后,它将可以在这些对象中被引用,
|
||||
例如:
|
||||
|
||||
```
|
||||
{
|
||||
"outbounds": [
|
||||
{
|
||||
"snippet": "snippet-name"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
关于片段的更多信息,可以点击片段菜单中的问号图标查看说明。
|
||||
|
||||
### 流控(Flow Control / VLESS)
|
||||
|
||||
_该功能仅在 2.3.0 及以上版本中可用。_
|
||||
|
||||
默认情况下,Remnawave 会自动为以下配置添加 `flow` 参数:
|
||||
VLESS + TLS、REALITY + RAW 或 TCP。
|
||||
|
||||
如果你希望手动覆盖这一默认行为,可以在 `settings` 对象中显式指定 `flow` 字段。
|
||||
|
||||
```json
|
||||
"settings": {
|
||||
"flow": "",
|
||||
"clients": [],
|
||||
"decryption": "none"
|
||||
},
|
||||
```
|
||||
|
||||
可用的 `flow` 值如下:
|
||||
|
||||
- `xtls-rprx-vision`
|
||||
- `""`
|
||||
|
||||
### Kcp with FinalMask
|
||||
|
||||
_This feature is available only in version 2.7.0 and above._
|
||||
|
||||
In some cases, you may need to specify a custom MTU (in the `kcpSettings` object) when using FinalMask. Unfortunately, Xray configuration does not clearly separate client and server MTU values.
|
||||
|
||||
```json
|
||||
{
|
||||
"mtu": 1350
|
||||
}
|
||||
```
|
||||
|
||||
Since Remnawave needs to generate the client-side configuration, we have added a custom field that does not exist in the original Xray configuration.
|
||||
|
||||
```json
|
||||
{
|
||||
"clientMtu": 70
|
||||
}
|
||||
```
|
||||
|
||||
The `clientMtu` parameter (if present) will be converted to `mtu` on the client side. This way, you can set a custom MTU for the client side.
|
||||
44
_panel-docs/help-articles/zh/PAGE_EXTERNAL_SQUADS.md
Normal file
@@ -0,0 +1,44 @@
|
||||
## 外部分组
|
||||
|
||||
通过使用外部分组,你可以在用户请求订阅时覆盖其使用的某些设置或模板。 _每个用户同一时间只能拥有一个活动的外部分组。_
|
||||
|
||||
例如,你可以为不同的用户群体设置不同的路由方案(如 Happ、v2rayTUN),而不同的路由方案也可以定义在模板中。
|
||||
|
||||
通过右侧的附加菜单,你可以快速为所有用户分配一个外部分组 (或反向操作,将所有用户从该外部分组中移除)。
|
||||
|
||||
如果用户没有被分配任何外部分组 - 则会使用 "**订阅(Subscription)**" 页面中的全局设置, 以及默认的 "**Default**" 客户端配置模板。
|
||||
|
||||
---
|
||||
|
||||
接下来,我们来逐步了解外部分组卡片中可用的设置。
|
||||
|
||||
### 模板覆盖(Template Override)
|
||||
|
||||
当用户请求订阅时,系统会根据请求来源的客户端类型为其提供相应的模板。 例如,如果客户端基于 Mihomo 内核运行,Remnawave 会自动识别,并提供 **Mihomo** 类型 的 **Default** 模板(可在模板管理页面进行设置)。
|
||||
|
||||
在 Remnawave 中,你可以为每种类型(Mihomo、Stash、Xray Json、Singbox、Clash)创建任意数量的模板,但默认情况下系统总是会提供 **Default** 模板。
|
||||
|
||||
**而外部分组中的此项设置,正是用于覆盖这一默认行为。**
|
||||
|
||||
举例来说,假设我们希望某个外部分组使用 _自定义模板(Custom Template)_ ,该模板属于 **Mihomo** 类型, 那么只需在对应选项中选择该模板并保存更改。 此后,当属于该外部分组的用户发起订阅请求时,他们将收到 _Custom Template_ 模板, 而不是 _Default_.
|
||||
|
||||
如果你将模板覆盖字段留空,则该分组中的用户仍会接收 _Default_ 模板。
|
||||
|
||||
_请注意,在 “请求订阅的应用(Response Rules)” 中的模板覆盖优先级高于本处设置。_
|
||||
|
||||
### 设置(订阅)
|
||||
|
||||
在此部分,你可以覆盖“订阅(Subscription)→ 设置(Settings)”中定义的全局配置。
|
||||
通过这种方式,你可以一次性为整个用户组覆盖多个参数。
|
||||
|
||||
请记住,如果某个参数被显式覆盖(包括空值),该值就会被应用。 只有删除覆盖(点击垃圾桶图标)才能取消覆盖。
|
||||
|
||||
例如,假设在全局设置中,我的订阅标题是 “Remnawave”, 但我想为 10 个特定用户将其改为 “Remnawave v.2.x”, 这时我只需在此部分中修改该参数,然后将此外部分组分配给这 10 位用户即可。
|
||||
|
||||
### 主机(Hosts)
|
||||
|
||||
延续上面的逻辑,在此部分中,你可以完全覆盖你在每个 **主机(Host)** 卡片中看到的某些参数。
|
||||
|
||||
**此处设置的覆盖值将应用于用户在订阅中收到的所有主机。**
|
||||
|
||||
例如,通过覆盖 `vlessRouteId` 参数,我们可以为特定用户组(即该外部分组中的用户)分配特定值,从而实现整组用户的 "_路由(route)_" 划分。 当然,这种路由设置的另一半逻辑在服务器端的配置文件(Config Profile)中定义。
|
||||
70
_panel-docs/help-articles/zh/PAGE_HOSTS.md
Normal file
@@ -0,0 +1,70 @@
|
||||
## 主机(Hosts)
|
||||
|
||||
简单来说,主机(Host) 是服务器配置在客户端侧的表现形式。 如果服务器端需要一个 **入站(Inbound)** 才能建立连接,那么客户端侧的用户就需要一个 **主机(Host)**。
|
||||
|
||||
一组主机(或称为 _列表_)代表一个订阅。 订阅是一个链接,当用户将此链接添加到客户端后,就会看到一个主机列表(也可以理解为“服务器列表”)。用户随后可以从中选择任意一个主机进行连接。
|
||||
|
||||
需要特别注意的是, **主机(Host)** 仅仅是你服务器配置的客户端解释形式。 例如,如果用户已经获取了订阅(也就是说,主机列表已经在他们手中),即使你在面板上禁用了该主机,用户 **仍然可以** 连接到该主机所指向的服务器。 但当用户更新订阅时,该主机将会从列表中消失。
|
||||
|
||||
由于主机直接绑定到一个入站(该入站位于配置文件中) - 主机会继承大部分来自入站的设置。 不过在某些情况下,可能需要覆盖或补充这些设置,这正是 **高级设置(Advanced)** 部分的用途。
|
||||
|
||||
---
|
||||
|
||||
当你创建一个新主机或编辑现有主机时,将会看到两个设置区域: **基础(Basic)** and **高级(Advanced)** 设置。
|
||||
|
||||
### 基础设置(Basic)
|
||||
|
||||
#### 备注(Remark)
|
||||
|
||||
此字段定义该主机在客户端中的显示名称。通常,这里会填写用户将要连接的国家或地区名称。
|
||||
|
||||
_提示:若希望客户端中显示国旗图标,可在备注开头添加国旗 emoji。_
|
||||
|
||||
#### 入站与配置文件选择(Inbound Selection & Profile)
|
||||
|
||||
如前所述,主机只是你服务器配置的客户端表示形式,因此创建主机时必须选择一个入站。根据你已有的入站、节点和配置文件数量,从菜单中选择合适的入站。
|
||||
|
||||
#### 地址与端口(Address and Port)
|
||||
|
||||
地址可以是域名或 IP 地址。 在大多数情况下,应填写用户将要连接的服务器域名或地址。端口通常与对应 **入站** 的端口相同,但在 _某些情况下也可能不同_ 。
|
||||
|
||||
_你还可以在地址栏中输入多个域名,例如: `node-1.com,node-2.com,node-3.com`. 虽然这看起来可以用于负载均衡,但实际上用户在请求订阅时只会随机获取其中一个地址,且并非真正的负载均衡。
|
||||
在用户刷新订阅(或触发自动更新)之前,他们的连接地址不会改变。_
|
||||
|
||||
#### 标签与节点(Tag and Nodes)
|
||||
|
||||
这些参数对最终用户不可见,主要是为了方便你(面板管理员)在管理大量主机时更容易区分。
|
||||
特别是“节点”字段的选择不影响功能 - **仅用于视觉标识和导航方便**。
|
||||
|
||||
---
|
||||
|
||||
### 高级设置(Advanced)
|
||||
|
||||
**在大多数情况下,除非你明确知道自己在做什么,否则不建议修改此部分内容。
|
||||
某些参数错误地修改后可能导致连接无法正常工作。
|
||||
请谨慎操作,并在应用更改前反复确认设置。**
|
||||
|
||||
以下只介绍几个主要项目:
|
||||
|
||||
#### SNI (ServerNames)
|
||||
|
||||
在某些场景下,你可能需要为特定主机覆盖入站(配置文件中的) `serverNames` 对象。
|
||||
|
||||
请记住, `serverNames` 本质上可以理解为 **Reality** 协议中的“_连接验证密码_”, 例如,如果你在此字段中手动指定了 `example.com`, 而入站中的 `serverNames` 定义如下:
|
||||
|
||||
```json
|
||||
"serverNames": [
|
||||
"example1.com",
|
||||
"example2.com"
|
||||
]
|
||||
```
|
||||
|
||||
此连接将无法工作,因为 `example.com` 不在允许的 `SNI`中。
|
||||
|
||||
#### 从地址覆盖 SNI(Override SNI from Address)
|
||||
|
||||
默认情况下,Remnawave 会取入站中 `serverNames` 数组的第一个值,作为客户端的 SNI。 若启用此选项,系统将使用你在“**基础设置**”中指定的地址作为 SNI 传递给客户端。
|
||||
|
||||
除此之外,本节中还值得注意的是 `vlessRouteId` 字段。 该字段是对 Xray Core 的一个小型抽象层,允许你更方便地使用 Xray 的 `vlessRoute` 功能。 <a href="https://xtls.github.io/en/config/routing.html#ruleobject">了解更多关于路由规则.</a>
|
||||
|
||||
---
|
||||
21
_panel-docs/help-articles/zh/PAGE_INTERNAL_SQUADS.md
Normal file
@@ -0,0 +1,21 @@
|
||||
## 内部分组
|
||||
|
||||
内部分组的主要目的在于为用户提供**访问控制** 。
|
||||
|
||||
内部分组与**配置文件(Profiles)** 及其**入站(Inbounds)** 直接关联。 你可以为一个内部分组分配任意数量的活动入站(这些入站存在于配置文件中)。 由于配置文件及其入站又与节点直接相关 – 因此通过使用内部分组, 我们可以精细地控制哪些用户或用户组可以访问哪些节点。
|
||||
|
||||
---
|
||||
|
||||
在每个分组卡片(列表视图中)上,你可以看到该分组的活动入站数量,以及分组内的成员数量(即属于该分组的用户)。
|
||||
|
||||
点击分组卡片中的“更多操作”按钮,你可以快速添加或移除所有用户。 如果你只想将某个分组分配给 _特定_ 用户 – 可以前往 **"用户(Users)"** 页面进行操作。
|
||||
|
||||
在管理用户与节点的访问权限时,有时会比较混乱——这时可以使用 **"可用节点(Available Nodes)"** 按钮,快速查看该分组可访问的节点。 请记住,在创建或修改一个 **节点**, 我们需要选择对应的 **配置文件** 并指定该配置文件中哪些 **入站** 会在该节点上启用。 而由于我们在内部分组中也会选择 **入站** , 因此可以通过这种关联关系,确定该分组 (以及其成员) 可以访问的具体节点。
|
||||
|
||||
---
|
||||
|
||||
例如,我们有两个用户组: **免费组(Free)** 和 **付费组(Paid)**. 我们希望 **免费** 用户只能访问 _服务器组 #1_, 而付费用户则可以访问 _服务器组 #1_ 和 _服务器组 #2_.
|
||||
|
||||
为此,我们可以创建两个分组: **Free** 和 **Premium**, 并在各自的分组中选择对应的入站。
|
||||
|
||||
当我们创建一个用户时,如果这是一个免费用户,只需为其启用 **Free** 内部分组。 而如果是付费用户,则可以同时启用**Free**和**Premium** (如果该用户需要访问所有节点/入站)。 当然,我们也可以只为付费用户启用一个分组 – **Premium**, 这样该用户将无法访问来自 **Free** 分组的节点或入站。
|
||||
144
blog/api-changelog/v232-v240.mdx
Normal file
@@ -0,0 +1,144 @@
|
||||
---
|
||||
title: API Changelog 2.3.2 vs. 2.4.0
|
||||
authors: remnawave
|
||||
tags: [api-changelog]
|
||||
date: 2025-12-19
|
||||
hide_table_of_contents: true
|
||||
---
|
||||
|
||||
# API Changelog v2.3.2 vs. v2.4.0
|
||||
|
||||
### New Endpoints: 14
|
||||
|
||||
- `GET /api/bandwidth-stats/nodes`
|
||||
- `GET /api/bandwidth-stats/nodes/realtime`
|
||||
- `GET /api/bandwidth-stats/nodes/{uuid}/users`
|
||||
- `GET /api/bandwidth-stats/nodes/{uuid}/users/legacy`
|
||||
- `GET /api/bandwidth-stats/users/{uuid}`
|
||||
- `GET /api/bandwidth-stats/users/{uuid}/legacy`
|
||||
- `GET /api/subscription-page-configs`
|
||||
- `PATCH /api/subscription-page-configs`
|
||||
- `POST /api/subscription-page-configs`
|
||||
- `POST /api/subscription-page-configs/actions/clone`
|
||||
- `POST /api/subscription-page-configs/actions/reorder`
|
||||
- `DELETE /api/subscription-page-configs/{uuid}`
|
||||
- `GET /api/subscription-page-configs/{uuid}`
|
||||
- `GET /api/subscriptions/subpage-config/{shortUuid}`
|
||||
|
||||
### Deleted Endpoints: 4
|
||||
|
||||
- `GET /api/nodes/usage/range`
|
||||
- `GET /api/nodes/usage/realtime`
|
||||
→ replaced with `GET /api/bandwidth-stats/nodes/realtime`
|
||||
- `GET /api/nodes/usage/{uuid}/users/range`
|
||||
→ replaced with `GET /api/bandwidth-stats/nodes/{uuid}/users/legacy`
|
||||
- `GET /api/users/stats/usage/{uuid}/range`
|
||||
→ replaced with `GET /api/bandwidth-stats/users/{uuid}/legacy`
|
||||
|
||||
### Modified Endpoints: 7
|
||||
|
||||
---
|
||||
|
||||
GET /api/external-squads
|
||||
|
||||
- Responses changed
|
||||
- Modified response: 200
|
||||
- Content changed
|
||||
- Modified media type: application/json
|
||||
- Schema changed
|
||||
- Properties changed
|
||||
- Modified property: response
|
||||
- Properties changed
|
||||
- Modified property: externalSquads
|
||||
- Items changed
|
||||
- Required changed
|
||||
- New required property: subpageConfigUuid
|
||||
- Properties changed
|
||||
- New property: subpageConfigUuid
|
||||
|
||||
PATCH /api/external-squads
|
||||
|
||||
- Request body changed
|
||||
- Content changed
|
||||
- Modified media type: application/json
|
||||
- Schema changed
|
||||
- Properties changed
|
||||
- New property: subpageConfigUuid
|
||||
- Responses changed
|
||||
- Modified response: 200
|
||||
- Content changed
|
||||
- Modified media type: application/json
|
||||
- Schema changed
|
||||
- Properties changed
|
||||
- Modified property: response
|
||||
- Required changed
|
||||
- New required property: subpageConfigUuid
|
||||
- Properties changed
|
||||
- New property: subpageConfigUuid
|
||||
|
||||
POST /api/external-squads
|
||||
|
||||
- Responses changed
|
||||
- Modified response: 201
|
||||
- Content changed
|
||||
- Modified media type: application/json
|
||||
- Schema changed
|
||||
- Properties changed
|
||||
- Modified property: response
|
||||
- Required changed
|
||||
- New required property: subpageConfigUuid
|
||||
- Properties changed
|
||||
- New property: subpageConfigUuid
|
||||
|
||||
POST /api/external-squads/actions/reorder
|
||||
|
||||
- Responses changed
|
||||
- Modified response: 200
|
||||
- Content changed
|
||||
- Modified media type: application/json
|
||||
- Schema changed
|
||||
- Properties changed
|
||||
- Modified property: response
|
||||
- Properties changed
|
||||
- Modified property: externalSquads
|
||||
- Items changed
|
||||
- Required changed
|
||||
- New required property: subpageConfigUuid
|
||||
- Properties changed
|
||||
- New property: subpageConfigUuid
|
||||
|
||||
GET /api/external-squads/\{uuid\}
|
||||
|
||||
- Responses changed
|
||||
- Modified response: 200
|
||||
- Content changed
|
||||
- Modified media type: application/json
|
||||
- Schema changed
|
||||
- Properties changed
|
||||
- Modified property: response
|
||||
- Required changed
|
||||
- New required property: subpageConfigUuid
|
||||
- Properties changed
|
||||
- New property: subpageConfigUuid
|
||||
|
||||
PATCH /api/nodes
|
||||
|
||||
- Request body changed
|
||||
- Content changed
|
||||
- Modified media type: application/json
|
||||
- Schema changed
|
||||
- Properties changed
|
||||
- Modified property: consumptionMultiplier
|
||||
- Min changed from 0.1 to 0
|
||||
- Max changed from null to 100
|
||||
|
||||
POST /api/nodes
|
||||
|
||||
- Request body changed
|
||||
- Content changed
|
||||
- Modified media type: application/json
|
||||
- Schema changed
|
||||
- Properties changed
|
||||
- Modified property: consumptionMultiplier
|
||||
- Min changed from 0.1 to 0
|
||||
- Max changed from null to 100
|
||||
65
blog/api-changelog/v244-v250.mdx
Normal file
@@ -0,0 +1,65 @@
|
||||
---
|
||||
title: API Changelog 2.4.4 vs. 2.5.0
|
||||
authors: remnawave
|
||||
tags: [api-changelog]
|
||||
date: 2026-01-07
|
||||
hide_table_of_contents: true
|
||||
---
|
||||
|
||||
# API Changelog 2.4.4 vs. 2.5.0
|
||||
|
||||
#### GET /api/system/metadata
|
||||
|
||||
- new endpoint added
|
||||
|
||||
#### GET /api/external-squads
|
||||
|
||||
- :warning: removed the required property 'response/externalSquads/items/customRemarks/emptyInternalSquads' from the response with the '200' status
|
||||
- added the required property 'response/externalSquads/items/customRemarks/HWIDMaxDevicesExceeded' to the response with the '200' status
|
||||
- added the required property 'response/externalSquads/items/customRemarks/HWIDNotSupported' to the response with the '200' status
|
||||
|
||||
#### PATCH /api/external-squads
|
||||
|
||||
- :warning: added the new required request property 'customRemarks/HWIDMaxDevicesExceeded'
|
||||
- :warning: added the new required request property 'customRemarks/HWIDNotSupported'
|
||||
- :warning: removed the required property 'response/customRemarks/emptyInternalSquads' from the response with the '200' status
|
||||
- :warning: removed the request property 'customRemarks/emptyInternalSquads'
|
||||
- added the required property 'response/customRemarks/HWIDMaxDevicesExceeded' to the response with the '200' status
|
||||
- added the required property 'response/customRemarks/HWIDNotSupported' to the response with the '200' status
|
||||
|
||||
#### POST /api/external-squads
|
||||
|
||||
- :warning: removed the required property 'response/customRemarks/emptyInternalSquads' from the response with the '201' status
|
||||
- added the required property 'response/customRemarks/HWIDMaxDevicesExceeded' to the response with the '201' status
|
||||
- added the required property 'response/customRemarks/HWIDNotSupported' to the response with the '201' status
|
||||
|
||||
#### POST /api/external-squads/actions/reorder
|
||||
|
||||
- :warning: removed the required property 'response/externalSquads/items/customRemarks/emptyInternalSquads' from the response with the '200' status
|
||||
- added the required property 'response/externalSquads/items/customRemarks/HWIDMaxDevicesExceeded' to the response with the '200' status
|
||||
- added the required property 'response/externalSquads/items/customRemarks/HWIDNotSupported' to the response with the '200' status
|
||||
|
||||
#### GET /api/external-squads/\{uuid\}
|
||||
|
||||
- :warning: removed the required property 'response/customRemarks/emptyInternalSquads' from the response with the '200' status
|
||||
- added the required property 'response/customRemarks/HWIDMaxDevicesExceeded' to the response with the '200' status
|
||||
- added the required property 'response/customRemarks/HWIDNotSupported' to the response with the '200' status
|
||||
|
||||
#### GET /api/subscription-settings
|
||||
|
||||
- :warning: removed the required property 'response/customRemarks/emptyInternalSquads' from the response with the '200' status
|
||||
- added the required property 'response/customRemarks/HWIDMaxDevicesExceeded' to the response with the '200' status
|
||||
- added the required property 'response/customRemarks/HWIDNotSupported' to the response with the '200' status
|
||||
|
||||
#### PATCH /api/subscription-settings
|
||||
|
||||
- :warning: added the new required request property 'customRemarks/HWIDMaxDevicesExceeded'
|
||||
- :warning: added the new required request property 'customRemarks/HWIDNotSupported'
|
||||
- :warning: removed the required property 'response/customRemarks/emptyInternalSquads' from the response with the '200' status
|
||||
- :warning: removed the request property 'customRemarks/emptyInternalSquads'
|
||||
- added the required property 'response/customRemarks/HWIDMaxDevicesExceeded' to the response with the '200' status
|
||||
- added the required property 'response/customRemarks/HWIDNotSupported' to the response with the '200' status
|
||||
|
||||
#### POST /api/users/\{uuid\}/actions/revoke
|
||||
|
||||
- added the new optional request property 'revokeOnlyPasswords'
|
||||
9
blog/authors.yml
Normal file
@@ -0,0 +1,9 @@
|
||||
remnawave:
|
||||
name: Remnawave
|
||||
title: Maintainer
|
||||
url: https://t.me/remnawave
|
||||
image_url: https://docs.rw/img/logo.svg
|
||||
page: false
|
||||
socials:
|
||||
telegram: https://t.me/remnawave
|
||||
github: remnawave
|
||||
BIN
blog/misc/new-profiles-and-squads/config_profiles_preview_1.png
Normal file
|
After Width: | Height: | Size: 330 KiB |
BIN
blog/misc/new-profiles-and-squads/config_profiles_preview_2.png
Normal file
|
After Width: | Height: | Size: 370 KiB |
BIN
blog/misc/new-profiles-and-squads/config_profiles_preview_3.png
Normal file
|
After Width: | Height: | Size: 319 KiB |
BIN
blog/misc/new-profiles-and-squads/config_profiles_preview_4.png
Normal file
|
After Width: | Height: | Size: 331 KiB |
@@ -0,0 +1,103 @@
|
||||
---
|
||||
title: Summing up Config&Profiles
|
||||
authors: remnawave
|
||||
tags: [misc]
|
||||
date: 2025-06-30
|
||||
---
|
||||
|
||||
В этой статье мы проведем небольшой обзор новой системы – Профилей Конфигураций (Config Profiles) и Внутренних Сквадов (Internal Squads), которая будет доступна с релизом 2.0 (планируется в середине июля/начале августа 2025-го года).
|
||||
|
||||
<!-- truncate -->
|
||||
|
||||
## Как это реализивано в 1.x?
|
||||
|
||||
Итак, в версии 1.x это работает довольно просто и банально.
|
||||
|
||||
У нас есть центральный конфиг ядра – Xray Config (в соотвествующем разделе в админ-панели). Из этого конфига панель извлекает все **Inbound'ы** и их **тэги**. Тэг является уникальным и явно идентифицирует Inbound.
|
||||
|
||||
При подключении Remnawave Node вы выбираете `Inbound'ы`, которые будут находиться в конфиге ядра этой ноды.
|
||||
|
||||
С другой стороны, при карточке пользователя вы также выбираете активные `Inbound'ы`, доступные этому пользователя.
|
||||
|
||||
Такой базовый подход хоть и довольно просто реализован, но имеет ряд недостатков:
|
||||
|
||||
- **Конфигурация ядра глобально – одна для всех нод.**
|
||||
Если вам жизненно необходимо иметь полностью разные конфиги на каждой ноде – это начинает быть серьезной проблемой.
|
||||
- **При большом количестве `Inbound'ов` управление пользователями начинает приносить головную боль.**
|
||||
Из-за того, что пользователь привязывается напрямую к определенным `Inbound'у`, при их частом изменении управление пользователями становится очень сложным.
|
||||
- **При изменении общего конфига перезапускаются все ноды.** Если вы сделали ошибку в конфиге, то пользователи не смогут подключиться ни к одной ноде, пока вы не исправите ошибку.
|
||||
|
||||
<img src={require('./remnawave_1x_sum.png').default} width="100%" style={{borderRadius: '8px'}} alt="Remna Wave 1x Sum" />
|
||||
|
||||
Эту систему можно отобразить в виде упрощенной схемы выше.
|
||||
|
||||
И закрепим материал: глобально у нас есть один центральный конфиг ядра, в карточке ноды мы выбираем, какие `Inbound'ы` будут физически присутствовать в конфиге ядра этой ноды, а затем в карточке пользователя мы выбираем, какие `Inbound'ы` будут доступны для этого пользователя. По итогу Remnawave при старте ноды собирает готовый конфиг и отправляет его в ядро.
|
||||
|
||||
## Как это будет в 2.x?
|
||||
|
||||
Начиная с версии 2.0 мы вводим новые понятия в рамках панели:
|
||||
|
||||
- **Профили конфигурации** (Config Profiles) – каждый **профиль конфигурации** – это полноценный конфиг ядра. Вы можете создать сколько угодно профилей конфигурации – но тэги Inbound'ов должны быть глобально уникальные. После сохранения профиля Remnawave извлечет все тэги `Inbound'ов` этого профиля и сохранит их в базу данных.
|
||||
- **Внутренние сквады** (Internal Squads) – пользовательские группы. В каждом из сквадов вы можете выбрать, какие `Inbound'ы` будут в нем доступны. Можно выбирать любые `Inbound'ы` со всех доступных **Профилей конфигурации**.
|
||||
|
||||
### Профили конфигурации (Config Profiles) {#config-profiles}
|
||||
|
||||
<img src={require('./config_profiles_preview_1.png').default} width="100%" style={{borderRadius: '8px'}} alt="Config Profiles Preview 1" />
|
||||
|
||||
В новом разделе **Профили конфигурации** можно создать новые профили, скачать JSON-файл уже существующего профиля, удалить профиль.
|
||||
|
||||
Редактор в целом не претерпел изменений и выглядит так же, как и раньше.
|
||||
|
||||
<img src={require('./config_profiles_preview_2.png').default} width="100%" style={{borderRadius: '8px'}} alt="Config Profiles Preview 1" />
|
||||
|
||||
Как уже упоминалось выше – каждый **Профиль конфигурации** – это полноценный конфиг ядра, который включает в себя не только массив с Inbounds, но и всю остальную конфигурацию ядра.
|
||||
|
||||
Плавно перейдем в раздел **Ноды** и посмотрим, как теперь будет выглядеть выбор `Inbound'ов` для ноды.
|
||||
|
||||
<img src={require('./config_profiles_preview_3.png').default} width="100%" style={{borderRadius: '8px'}} alt="Config Profiles Preview 1" />
|
||||
|
||||
<img src={require('./config_profiles_preview_4.png').default} width="100%" style={{borderRadius: '8px'}} alt="Config Profiles Preview 1" />
|
||||
|
||||
Итак, мы видим, что в новой системе мы можем выбрать **Профиль конфигурации**, который будет активен на конкретной ноде, и **какие `Inbound'ы` из выбранного Профиля будут активированы на этой ноде**.
|
||||
|
||||
Просуммируем:
|
||||
|
||||
- Вы можете создавать сколько угодно **Профилей конфигурации** – но тэги `Inbound'ов` должны быть глобально уникальные.
|
||||
- Вы можете выбрать **Профиль конфигурации** для ноды и указать, какие `Inbound'ы` из выбранного Профиля будут активированы на этой ноде.
|
||||
|
||||
### Внутренние сквады (Internal Squads) {#internal-squads}
|
||||
|
||||
Перейдем к **Внутренним сквадам** (Internal Squads). В общем списке доступна небольшая статистика по сквадам: количество пользователей, количество активных `Inbound'ов` по каждому скваду.
|
||||
|
||||
<img src={require('./internal_squads_preview_1.png').default} width="100%" style={{borderRadius: '8px'}} alt="Config Profiles Preview 1" />
|
||||
|
||||
<img src={require('./internal_squads_preview_2.png').default} width="100%" style={{borderRadius: '8px'}} alt="Config Profiles Preview 1" />
|
||||
|
||||
В карточке редактирования сквада вы можете указать активные для этого сквада `Inbound'ы`.
|
||||
Как уже упоминалось выше – вы можете выбирать любые `Inbound'ы` со всех доступных **Профилей конфигурации**.
|
||||
|
||||
Внутренние сквады, в свою очередь, связаны с пользователями.
|
||||
|
||||
<img src={require('./internal_squads_preview_3.png').default} width="100%" style={{borderRadius: '8px'}} alt="Config Profiles Preview 1" />
|
||||
|
||||
В карточке пользователя доступен выбор сквадов: пользователю можно присвоить несколько сквадов одновременно.
|
||||
|
||||
Также в карточке пользователя есть шорткат к быстрому редактированию конкретного сквада.
|
||||
|
||||
<img src={require('./internal_squads_preview_4.png').default} width="100%" style={{borderRadius: '8px'}} alt="Config Profiles Preview 1" />
|
||||
|
||||
При таком уровне абстракции администратор не может сразу понять, к каким нодам привязан конкретный пользователь. Рассмотрим возможный выход из ситуации.
|
||||
|
||||
В карточке пользователя доступна новая кнопка – **View Accessible Nodes**.
|
||||
|
||||
<img src={require('./internal_squads_preview_5.png').default} width="100%" style={{borderRadius: '8px'}} alt="Config Profiles Preview 1" />
|
||||
|
||||
В данном разделе отображаются все ноды, доступные пользователю, а также поясняется, почему именно у него есть доступ к каждой из них - в частности, из‑за членства в соответствующих сквадах.
|
||||
|
||||
### Итоги
|
||||
|
||||
Ниже представлена схема новой системы.
|
||||
|
||||
<img src={require('./remnawave_2x_squads.png').default} width="100%" style={{borderRadius: '8px'}} alt="Remnawave 2x Squads" />
|
||||
|
||||
Новая система устраняет перечисленные недостатки старой: при изменении профиля конфигурации (конфига ядра) перезапускаются только ноды, использующие этот профиль.
|
||||
BIN
blog/misc/new-profiles-and-squads/internal_squads_preview_1.png
Normal file
|
After Width: | Height: | Size: 348 KiB |
BIN
blog/misc/new-profiles-and-squads/internal_squads_preview_2.png
Normal file
|
After Width: | Height: | Size: 371 KiB |
BIN
blog/misc/new-profiles-and-squads/internal_squads_preview_3.png
Normal file
|
After Width: | Height: | Size: 406 KiB |
BIN
blog/misc/new-profiles-and-squads/internal_squads_preview_4.png
Normal file
|
After Width: | Height: | Size: 426 KiB |
BIN
blog/misc/new-profiles-and-squads/internal_squads_preview_5.png
Normal file
|
After Width: | Height: | Size: 376 KiB |
BIN
blog/misc/new-profiles-and-squads/remnawave_1x_sum.png
Normal file
|
After Width: | Height: | Size: 257 KiB |
BIN
blog/misc/new-profiles-and-squads/remnawave_2x_squads.png
Normal file
|
After Width: | Height: | Size: 399 KiB |
86
blog/releases/1.3.1/index.mdx
Normal file
@@ -0,0 +1,86 @@
|
||||
---
|
||||
title: Release v1.3.1
|
||||
authors: remnawave
|
||||
tags: [release]
|
||||
date: 2025-02-24
|
||||
---
|
||||
|
||||
# Release v1.3.1
|
||||
|
||||
**🚧 Breaking Changes Alert 🚧**
|
||||
|
||||
This release contains breaking changes. Please review the following sections carefully before upgrading.
|
||||
|
||||
{/* truncate */}
|
||||
|
||||
## 🔄 Breaking Changes
|
||||
|
||||
### Metrics Port Configuration
|
||||
|
||||
- Prometheus metrics endpoint now runs on a separate port
|
||||
- Added new `METRICS_PORT` environment variable
|
||||
- Metrics endpoint path changed from `/api/metrics` to `/metrics`
|
||||
- No longer served on the main application port. Please use new `METRICS_PORT` environment variable to access metrics.
|
||||
|
||||
### 🧬 API changes
|
||||
|
||||
1. All user endpoints now include `lastConnectedNode` information
|
||||
|
||||
2. Enhanced subscription information in responses
|
||||
|
||||
3. Traffic reset strategy changed
|
||||
|
||||
`CALENDAR_MONTH`, `YEAR` is **removed**.
|
||||
|
||||
`MONTH` now uses the same strategy as `CALENDAR_MONTH` before.
|
||||
|
||||
:::warning
|
||||
**If you use API, please review your codebase to reflect these changes.**
|
||||
:::
|
||||
|
||||
:::info
|
||||
There is no need to manually change reset strategy for existing users, it will be changed automatically when you upgrade.
|
||||
:::
|
||||
|
||||
4. Traffic reset strategy also use new logic.
|
||||
|
||||
`DAY` – every day at 00:00 UTC
|
||||
|
||||
`WEEK` – every week at Monday 00:00 UTC (night from Sunday to Monday)
|
||||
|
||||
`MONTH` – every month at the first day of month at 00:00 UTC
|
||||
|
||||
## 🔧 How to Upgrade
|
||||
|
||||
1. Add the required new environment variables:
|
||||
- `METRICS_PORT`
|
||||
- `API_INSTANCES`
|
||||
2. Update your monitoring configuration to use the new metrics port
|
||||
3. Update your API clients. Change deprecated `CALENDAR_MONTH`, `YEAR` to `MONTH` or `WEEK` or `DAY`.
|
||||
|
||||
:::warning
|
||||
It will be impossible to downgrade to previous version, because of migration of reset strategy.
|
||||
:::
|
||||
|
||||
## ✨ New Features
|
||||
|
||||
### Multiple Instances Support
|
||||
|
||||
- Bulk user deletion is now available. Delete many users with selected status with ease.
|
||||
- Added support for running multiple API instances
|
||||
- New `API_INSTANCES` environment variable to control instance scaling
|
||||
- Flexible scaling options:
|
||||
- `max`: Utilize all available CPU cores
|
||||
- `<number>`: Run a specific number of instances
|
||||
- `-1`: Use all cores except one
|
||||
|
||||
> ⚠️ **Important**: Never set instance count higher than your server's physical core count
|
||||
|
||||
### Frontend
|
||||
|
||||
- i18n in now supported. Currently, Russian, English and Persian languages are supported.
|
||||
|
||||
## 🐛 Bug Fixes
|
||||
|
||||
- [x] Fixed an error, when you tried to use Telegram bot for notifications, but it is already had getUpdates or webhook active.
|
||||
- [x] Other minor fixes and improvements.
|
||||
56
blog/releases/2.1.0/index.md
Normal file
@@ -0,0 +1,56 @@
|
||||
---
|
||||
title: Release v2.1.0
|
||||
authors: remnawave
|
||||
tags: [release]
|
||||
date: 2025-08-13
|
||||
---
|
||||
|
||||
# Release v2.1.0
|
||||
|
||||
**🚧 Полное обновление обязательно 🚧**
|
||||
|
||||
Этот релиз содержит обновления всех компонентов Remnawave. Пожалуйста, внимательно ознакомьтесь с этим документом перед обновлением.
|
||||
|
||||
<!-- truncate -->
|
||||
|
||||
Хоть и новая версия панели _будет_ работать со старой версией Remnawave Node (до v2.1.0), мы настоятельно рекомендуем обновить Remnawave Node до версии v2.1.0.
|
||||
|
||||
## Remnawave Panel v2.1.0
|
||||
|
||||
### 🔄 Breaking Changes
|
||||
|
||||
- Через API (Patch метод в UsersController) более невозможно обновить статус пользователя на **LIMITED**, **EXPIRED**.
|
||||
|
||||
### Обновление
|
||||
|
||||
```bash
|
||||
cd /opt/remnawave && docker compose pull remnawave && docker compose down && docker compose up -d && docker compose logs -f -t
|
||||
```
|
||||
|
||||
## Remnawave Node v2.1.0
|
||||
|
||||
### 🔄 Breaking Changes
|
||||
|
||||
- Версия Remnawave Node v2.1.0 несовместима с версиями панели до v2.1.0.
|
||||
|
||||
### Прочие изменения
|
||||
|
||||
- Версия Xray Core обновлена до v25.8.3.
|
||||
|
||||
### Обновление
|
||||
|
||||
```bash
|
||||
cd /opt/remnanode && docker compose pull remnanode && docker compose down && docker compose up -d && docker compose logs -f -t
|
||||
```
|
||||
|
||||
## Remnawave Subscription Page v6.0.0
|
||||
|
||||
В версии v6.0.0 был обновлен формат `app-config.json` до новой версии, которая позволяет отключить неиспользуемые языки, а так же кастомизировать имя бренда и добавить логотип.
|
||||
|
||||
Встроенный в панель билдер был так же обновлен для поддержки нового формата `app-config.json`.
|
||||
|
||||
### Обновление
|
||||
|
||||
```bash
|
||||
cd /opt/remnawave/subscription && docker compose pull && docker compose down && docker compose up -d && docker compose logs -f -t
|
||||
```
|
||||
15
blog/tags.yaml
Normal file
@@ -0,0 +1,15 @@
|
||||
blog:
|
||||
release:
|
||||
description: "Blog posts about Remnawave Panel's new releases"
|
||||
development:
|
||||
description: 'Blog posts about the development of the Remnawave Panel'
|
||||
birth:
|
||||
endi:
|
||||
i18n:
|
||||
beta:
|
||||
search:
|
||||
documentation:
|
||||
profilo:
|
||||
adoption:
|
||||
unlisted:
|
||||
new:
|
||||
203
blog/updating-guides/updating-to-1.4.x/index.md
Normal file
@@ -0,0 +1,203 @@
|
||||
---
|
||||
title: Updating from 1.3.x to 1.4.x
|
||||
authors: remnawave
|
||||
tags: [updating-guides]
|
||||
date: 2025-03-14
|
||||
---
|
||||
|
||||
# Release v1.4.x
|
||||
|
||||
<Button
|
||||
label="Check out full changelog"
|
||||
variant="secondary"
|
||||
outline
|
||||
link="https://hub.remna.st/changelog/remnawave-v1-4-0"
|
||||
/>
|
||||
|
||||
<!-- truncate -->
|
||||
|
||||
## Remnawave Panel
|
||||
|
||||
### Updating backend
|
||||
|
||||
1. Update docker-compose.yml.
|
||||
|
||||
```bash
|
||||
cd /opt/remnawave && nano docker-compose.yml
|
||||
```
|
||||
|
||||
2. Replace your current configuration with the new one:
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
services:
|
||||
remnawave-db:
|
||||
image: postgres:17
|
||||
container_name: 'remnawave-db'
|
||||
hostname: remnawave-db
|
||||
restart: always
|
||||
env_file:
|
||||
- .env
|
||||
environment:
|
||||
- POSTGRES_USER=${POSTGRES_USER}
|
||||
- POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
|
||||
- POSTGRES_DB=${POSTGRES_DB}
|
||||
- TZ=UTC
|
||||
ports:
|
||||
- '127.0.0.1:6767:5432'
|
||||
volumes:
|
||||
- remnawave-db-data:/var/lib/postgresql/data
|
||||
networks:
|
||||
- remnawave-network
|
||||
healthcheck:
|
||||
test: ['CMD-SHELL', 'pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}']
|
||||
interval: 3s
|
||||
timeout: 10s
|
||||
retries: 3
|
||||
|
||||
remnawave:
|
||||
image: remnawave/backend:latest
|
||||
container_name: 'remnawave'
|
||||
hostname: remnawave
|
||||
restart: always
|
||||
ports:
|
||||
- '127.0.0.1:3000:3000'
|
||||
env_file:
|
||||
- .env
|
||||
networks:
|
||||
- remnawave-network
|
||||
// highlight-next-line-green
|
||||
depends_on:
|
||||
// highlight-next-line-green
|
||||
remnawave-db:
|
||||
// highlight-next-line-green
|
||||
condition: service_healthy
|
||||
// highlight-next-line-green
|
||||
remnawave-redis:
|
||||
// highlight-next-line-green
|
||||
condition: service_healthy
|
||||
|
||||
// highlight-next-line-green
|
||||
remnawave-redis:
|
||||
// highlight-next-line-green
|
||||
image: valkey/valkey:8.0.2-alpine
|
||||
// highlight-next-line-green
|
||||
container_name: remnawave-redis
|
||||
// highlight-next-line-green
|
||||
hostname: remnawave-redis
|
||||
// highlight-next-line-green
|
||||
restart: always
|
||||
// highlight-next-line-green
|
||||
networks:
|
||||
// highlight-next-line-green
|
||||
- remnawave-network
|
||||
// highlight-next-line-green
|
||||
volumes:
|
||||
// highlight-next-line-green
|
||||
- remnawave-redis-data:/data
|
||||
// highlight-next-line-green
|
||||
healthcheck:
|
||||
// highlight-next-line-green
|
||||
test: ['CMD', 'valkey-cli', 'ping']
|
||||
// highlight-next-line-green
|
||||
interval: 3s
|
||||
// highlight-next-line-green
|
||||
timeout: 10s
|
||||
// highlight-next-line-green
|
||||
retries: 3
|
||||
|
||||
networks:
|
||||
remnawave-network:
|
||||
name: remnawave-network
|
||||
driver: bridge
|
||||
external: false
|
||||
|
||||
volumes:
|
||||
remnawave-db-data:
|
||||
driver: local
|
||||
external: false
|
||||
name: remnawave-db-data
|
||||
// highlight-next-line-green
|
||||
remnawave-redis-data:
|
||||
// highlight-next-line-green
|
||||
driver: local
|
||||
// highlight-next-line-green
|
||||
external: false
|
||||
// highlight-next-line-green
|
||||
name: remnawave-redis-data
|
||||
```
|
||||
|
||||
3. Moving on to the .env file.
|
||||
|
||||
```bash
|
||||
cd /opt/remnawave && nano .env
|
||||
```
|
||||
|
||||
4. Remove old .env variables:
|
||||
|
||||
```title=".env"
|
||||
// highlight-next-line-red
|
||||
SUB_SUPPORT_URL
|
||||
// highlight-next-line-red
|
||||
SUB_PROFILE_TITLE
|
||||
// highlight-next-line-red
|
||||
SUB_UPDATE_INTERVAL
|
||||
// highlight-next-line-red
|
||||
SUB_WEBPAGE_URL
|
||||
// highlight-next-line-red
|
||||
EXPIRED_USER_REMARKS
|
||||
// highlight-next-line-red
|
||||
DISABLED_USER_REMARKS
|
||||
// highlight-next-line-red
|
||||
LIMITED_USER_REMARKS
|
||||
// highlight-next-line-red
|
||||
SUPERADMIN_PASSWORD
|
||||
// highlight-next-line-red
|
||||
SUPERADMIN_USERNAME
|
||||
```
|
||||
|
||||
Don't worry about the removed variables, they are moved to dashboard settings.
|
||||
Check out "Subscription Settings" section in dashboard.
|
||||
|
||||
Superadmin credentials now is stored in database and you will be prompted to create a superadmin account after updating.
|
||||
|
||||
1. Add new .env variables:
|
||||
|
||||
```title=".env"
|
||||
// highlight-next-line-green
|
||||
### REDIS ###
|
||||
// highlight-next-line-green
|
||||
REDIS_HOST=remnawave-redis
|
||||
// highlight-next-line-green
|
||||
REDIS_PORT=6379
|
||||
```
|
||||
|
||||
6. Going live
|
||||
|
||||
```bash
|
||||
docker compose pull && docker compose down && docker compose up -d && docker compose logs -f -t
|
||||
```
|
||||
|
||||
### About subscription templates
|
||||
|
||||
In previous versions of Remnawave, you could can mount custom templates for Sing-box, Mihomo, and Stash with setup similar to this:
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
volumes:
|
||||
- ./custom/configs/clash/stash_template.yml:/var/lib/remnawave/configs/stash/stash_template.yml
|
||||
- ./custom/configs/clash/clash_template.yml:/var/lib/remnawave/configs/clash/clash_template.yml
|
||||
- ./custom/configs/singbox/singbox_legacy.json:/var/lib/remnawave/configs/singbox/singbox_legacy.json
|
||||
- ./custom/configs/singbox/singbox_template.json:/var/lib/remnawave/configs/singbox/singbox_template.json
|
||||
```
|
||||
|
||||
In v1.4.x, we've removed support of _mounting_ custom templates from docker-compose.yml.
|
||||
|
||||
Now, you can only use templates from dashboard.
|
||||
Check out new section in dashboard `Templates`.
|
||||
|
||||
## Remnawave Node (Remnanode)
|
||||
|
||||
1. Update with command:
|
||||
|
||||
```bash
|
||||
cd /opt/remnanode && docker compose pull && docker compose down && docker compose up -d && docker compose logs -f -t
|
||||
```
|
||||
69
blog/updating-guides/updating-to-1.5.x/index.md
Normal file
@@ -0,0 +1,69 @@
|
||||
---
|
||||
title: Updating from to 1.5.x
|
||||
authors: remnawave
|
||||
tags: [updating-guides]
|
||||
date: 2025-04-06
|
||||
---
|
||||
|
||||
# Release v1.5.x
|
||||
|
||||
<Button
|
||||
label="Check out full changelog"
|
||||
variant="secondary"
|
||||
outline
|
||||
link="https://hub.remna.st/changelog/remnawave-v1-5-0"
|
||||
/>
|
||||
|
||||
<!-- truncate -->
|
||||
|
||||
### Warning
|
||||
|
||||
:::danger
|
||||
|
||||
It is necessary to update the Remnawave Node (Remnanode) to v1.5.x **AFTER** updating the Remnawave Panel.
|
||||
|
||||
:::
|
||||
|
||||
## Remnawave Panel
|
||||
|
||||
:::warning
|
||||
Open you current Remnawave Panel in browser and logout.
|
||||
:::
|
||||
|
||||
### 1. Update Remnawave Panel
|
||||
|
||||
```bash
|
||||
docker compose pull && docker compose down && docker compose up -d && docker compose logs -f -t
|
||||
```
|
||||
|
||||
### 2. Recreate admin user with RESCUE CLI
|
||||
|
||||
1.5.x version of Remnawave Panel uses a new password hashing algorithm, so old admin user will not be able to login.
|
||||
|
||||
```bash
|
||||
docker exec -it remnawave remnawave
|
||||
```
|
||||
|
||||
After entering the Rescue CLI, select option 'Reset superadmin' and follow the instructions.
|
||||
|
||||
### 3. Open Remnawave Panel
|
||||
|
||||
You will be prompted to create a new superadmin user.
|
||||
|
||||
### 4. Getting new SSL_CERT
|
||||
|
||||
In Remnawave Dashboard, go to `Nodes` -> `Management` and copy new `SSL_CERT`.
|
||||
|
||||
### 5. Update Remnawave Node (Remnanode)
|
||||
|
||||
Firstly, update SSL_CERT in the `.env` file with new one.
|
||||
|
||||
```bash
|
||||
cd /opt/remnanode && nano .env
|
||||
```
|
||||
|
||||
Then, update Remnawave Node (Remnanode) with command:
|
||||
|
||||
```bash
|
||||
docker compose pull && docker compose down && docker compose up -d && docker compose logs -f -t
|
||||
```
|
||||
148
blog/updating-guides/upgrading-to-1.6.x/index.md
Normal file
@@ -0,0 +1,148 @@
|
||||
---
|
||||
title: Upgrading to 1.6.x
|
||||
authors: remnawave
|
||||
tags: [updating-guides]
|
||||
date: 2025-05-10
|
||||
---
|
||||
|
||||
# Release v1.6.x
|
||||
|
||||
<Button
|
||||
label="Check out full changelog"
|
||||
variant="secondary"
|
||||
outline
|
||||
link="https://hub.remna.st/changelog/remnawave-v1-6-0"
|
||||
/>
|
||||
|
||||
<!-- truncate -->
|
||||
|
||||
## Remnawave Panel
|
||||
|
||||
### API schema changed
|
||||
|
||||
Remnawave Panel API schema changed, so you need to update your API clients.
|
||||
|
||||
:::danger
|
||||
|
||||
**Release v1.6.x contains really breaking changes in API schema.**
|
||||
|
||||
Almost all endpoints are changed!
|
||||
|
||||
Please, review [new API schema](https://docs.rw/api) before updating.
|
||||
|
||||
:::
|
||||
|
||||
### Change .env variables
|
||||
|
||||
If you are using Telegram bot notifications, pleace review changes below:
|
||||
|
||||
```bash title="1.5.x .env"
|
||||
IS_TELEGRAM_ENABLED=true
|
||||
TELEGRAM_BOT_TOKEN=1234567890
|
||||
|
||||
TELEGRAM_ADMIN_ID=1234567890
|
||||
TELEGRAM_ADMIN_THREAD_ID=1234567890
|
||||
|
||||
NODES_NOTIFY_CHAT_ID=1
|
||||
NODES_NOTIFY_THREAD_ID=1
|
||||
```
|
||||
|
||||
And update them with new values:
|
||||
|
||||
```bash title="1.6.x .env"
|
||||
|
||||
# Disable/Enable Telegram notifications
|
||||
IS_TELEGRAM_NOTIFICATIONS_ENABLED=false
|
||||
|
||||
# Telegram bot token
|
||||
TELEGRAM_BOT_TOKEN=change_me
|
||||
|
||||
# Notifications about users
|
||||
TELEGRAM_NOTIFY_USERS_CHAT_ID=change_me
|
||||
|
||||
# Notifications about nodes
|
||||
TELEGRAM_NOTIFY_NODES_CHAT_ID=change_me
|
||||
|
||||
# Optional, if you want to send notifications to specific topics in Telegram group
|
||||
TELEGRAM_NOTIFY_USERS_THREAD_ID=
|
||||
TELEGRAM_NOTIFY_NODES_THREAD_ID=
|
||||
```
|
||||
|
||||
### Update Remnawave Panel
|
||||
|
||||
```bash
|
||||
docker compose pull && docker compose down && docker compose up -d && docker compose logs -f -t
|
||||
```
|
||||
|
||||
## Remnawave Subscription Page
|
||||
|
||||
The backend part of @remnawave/subscription-page has been fully rewritten with NestJS (TypeScript) from scratch.
|
||||
|
||||
### New .env file format and variables
|
||||
|
||||
```bash title=".env"
|
||||
|
||||
APP_PORT=3010
|
||||
|
||||
### Remnawave Panel URL, can be http://remnawave:3000 or https://panel.example.com
|
||||
REMNAWAVE_PANEL_URL=https://panel.example.com
|
||||
|
||||
|
||||
META_TITLE="Subscription page"
|
||||
META_DESCRIPTION="Subscription page description"
|
||||
|
||||
# Serve at custom root path, for example, this value can be: CUSTOM_SUB_PREFIX=sub
|
||||
# Do not place / at the start/end
|
||||
CUSTOM_SUB_PREFIX=
|
||||
|
||||
# Support Marzban links
|
||||
MARZBAN_LEGACY_LINK_ENABLED=false
|
||||
MARZBAN_LEGACY_SECRET_KEY=
|
||||
REMNAWAVE_API_TOKEN=
|
||||
|
||||
|
||||
# If you use "Caddy with security" addon, you can place here X-Api-Key, which will be applied to requests to Remnawave Panel.
|
||||
CADDY_AUTH_API_TOKEN=
|
||||
|
||||
|
||||
```
|
||||
|
||||
You can use with .env file or environment variables.
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
services:
|
||||
remnawave-subscription-page:
|
||||
image: remnawave/subscription-page:latest
|
||||
container_name: remnawave-subscription-page
|
||||
hostname: remnawave-subscription-page
|
||||
restart: always
|
||||
environment:
|
||||
- APP_PORT=3010
|
||||
- REMNAWAVE_PANEL_URL=https://panel.example.com # Can be http://remnawave:3000 or https://panel.example.com
|
||||
- META_TITLE="Subscription page"
|
||||
- META_DESCRIPTION="Subscription page description"
|
||||
ports:
|
||||
- '127.0.0.1:3010:3010'
|
||||
networks:
|
||||
- remnawave-network
|
||||
|
||||
networks:
|
||||
remnawave-network:
|
||||
driver: bridge
|
||||
external: true
|
||||
```
|
||||
|
||||
Also, pay attention if you are using custom app-config.json.
|
||||
|
||||
New correct path is `/opt/app/frontend/assets/app-config.json`.
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
volumes:
|
||||
- ./app-config.json:/opt/app/frontend/assets/app-config.json
|
||||
```
|
||||
|
||||
### Update Remnawave Subscription Page
|
||||
|
||||
```bash
|
||||
docker compose pull && docker compose down && docker compose up -d && docker compose logs -f -t
|
||||
```
|
||||
55
blog/updating-guides/upgrading-to-2.x/index.md
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: Upgrading to 2.x
|
||||
authors: remnawave
|
||||
tags: [updating-guides]
|
||||
date: 2025-07-29
|
||||
---
|
||||
|
||||
# Release v2.x
|
||||
|
||||
<!-- truncate -->
|
||||
|
||||
## Remnawave Panel
|
||||
|
||||
:::danger Внимание!
|
||||
Убедитесь, что вы сделали резервную копию базы данных перед обновлением. Релиз 2.x несовместим с предыдущими версиями и содержит критические изменения.
|
||||
:::
|
||||
|
||||
Как мы уже писали в блоге, новая версия полностью переосмысливает архитектуру инбаундов.
|
||||
|
||||
Рекомендуем ознакомиться с [новой архитектурой](/blog/misc/new-profiles-and-squads/explaining-new-profile-and-squads-system).
|
||||
|
||||
И, если вы сомневаетесь, ознакомьтесь со статьей – [Быстрый старт](/docs/learn/quick-start).
|
||||
|
||||
В целом весь процесс миграции будет бесшовным, но есть несколько моментов, которые нужно учитывать.
|
||||
|
||||
1. Все активные инбаунды на нодах будут перенесены в том виде, в котором они были на момент обновления. (активные = включенные)
|
||||
2. Будет создан один "внутренний сквад", в него будут добавлены все доступные инбаунды.
|
||||
3. Всем пользователям будет назначен внутренний сквад.
|
||||
|
||||
Из-за пунктов 2,3 – пользователи в своей подписке могут получить хосты, которые им не должны быть доступны.
|
||||
Поэтому перед обновлением рекомендуется выключить хосты, которые не должны быть доступны пользователям. Чуть позже вы сможете их включить.
|
||||
|
||||
После обновления, вы можете выключить лишние инбаунды в разделе "Внутренние сквады".
|
||||
|
||||
Итак, резюмируя:
|
||||
|
||||
1. Обязательно сделайте бекап базы данных. Обязательно.
|
||||
2. Выключите видимость хостов, которые не должны быть доступны всем пользователям, или только некоторым.
|
||||
3. Обновитесь до Remnawave Panel 2.x.
|
||||
4. После обновления, перейдите в раздел "Внутренние сквады" и выключите лишние инбаунды для единственного сквада.
|
||||
5. Верните видимость хостов, которые ранее были выключены.
|
||||
|
||||
### Обновление Remnawave Panel
|
||||
|
||||
```bash
|
||||
docker compose pull && docker compose down && docker compose up -d && docker compose logs -f -t
|
||||
```
|
||||
|
||||
## Remnawave Node
|
||||
|
||||
Хоть это и не обязательно, но мы рекомендуем обновить Remnawave Node до последней доступной версии.
|
||||
|
||||
```bash
|
||||
docker compose pull && docker compose down && docker compose up -d && docker compose logs -f -t
|
||||
```
|
||||
453
docs/awesome-remnawave.mdx
Normal file
@@ -0,0 +1,453 @@
|
||||
---
|
||||
sidebar_position: 7
|
||||
title: ❤️ Awesome Remnawave
|
||||
hide_title: true
|
||||
hide_table_of_contents: true
|
||||
description: 'Discover the amazing ecosystem of tools, scripts, and integrations built by the Remnawave community. From monitoring solutions to automation scripts, find everything you need to enhance your Remnawave experience.'
|
||||
image: '/awesome/awesome-preview.webp'
|
||||
---
|
||||
|
||||
import Button from '@site/src/components/Button'
|
||||
import ProjectCard from '@site/src/components/ProjectCard'
|
||||
import ProjectsGrid from '@site/src/components/ProjectsGrid'
|
||||
import HeroSection from '@site/src/components/HeroSection'
|
||||
import CategoryNav from '@site/src/components/CategoryNav'
|
||||
|
||||
import RemnavaweTelegramMiniAppGuide from '/docs/awesome-remnawave/\_install-guides/remnawave-telegram-mini-app.md'
|
||||
import RemnawaveManagementScriptsGuide from '/docs/awesome-remnawave/\_install-guides/remnawave-management-scripts.md'
|
||||
import RemnasetupGuide from '/docs/awesome-remnawave/\_install-guides/remnasetup.md'
|
||||
import AnsiblePlaybookGuide from '/docs/awesome-remnawave/\_install-guides/ansible-playbook.md'
|
||||
import RemnawaveReverseProxyGuide from '/docs/awesome-remnawave/\_install-guides/remnawave-reverse-proxy.md'
|
||||
import RemnawaveBackupRestoreGuide from '/docs/awesome-remnawave/\_install-guides/remnawave-backup-restore.md'
|
||||
import RemnawaveCloudflareNodes from '/docs/awesome-remnawave/\_install-guides/remnawave-cloudflare-nodes.md'
|
||||
import WarpNativeInstallerGuide from '/docs/awesome-remnawave/\_install-guides/warp-native-installer.md'
|
||||
import RemnavaweBedolagaBotGuide from '/docs/awesome-remnawave/\_install-guides/remnawave-bedolaga-bot.md'
|
||||
import RemnashopGuide from '/docs/awesome-remnawave/\_install-guides/remnashop.md'
|
||||
import RemnawaveBackuperGuide from '/docs/awesome-remnawave/\_install-guides/remnawave-backuper.md'
|
||||
import XrayCheckerGuide from '/docs/awesome-remnawave/\_install-guides/xray-checker.md'
|
||||
import WhiteboxGuide from '/docs/awesome-remnawave/\_install-guides/whitebox.md'
|
||||
import McpRemnawaveGuide from '/docs/awesome-remnawave/\_install-guides/mcp-remnawave.md'
|
||||
|
||||
<HeroSection
|
||||
title="❤️ Awesome Remnawave"
|
||||
subtitle="Discover the amazing ecosystem of tools, scripts, and integrations built by the Remnawave community. From monitoring solutions to automation scripts, find everything you need to enhance your Remnawave experience."
|
||||
/>
|
||||
|
||||
<CategoryNav
|
||||
categories={[
|
||||
{ id: 'monitoring-analytics', icon: '📊', title: 'Monitoring & Analytics' },
|
||||
{ id: 'commerce', icon: '💰', title: 'Commerce' },
|
||||
{ id: 'auto-installers', icon: '🚀', title: 'Auto-installers' },
|
||||
{ id: 'backup-restore', icon: '💾', title: 'Backup & Restore' },
|
||||
{ id: 'misc', icon: '🔧', title: 'Misc' },
|
||||
{ id: 'clients', icon: '🖥️', title: 'Clients' }
|
||||
|
||||
]}
|
||||
|
||||
/>
|
||||
|
||||
<CategorySection
|
||||
id="monitoring-analytics"
|
||||
title="Monitoring & Analytics"
|
||||
description="Tools for monitoring, analyzing, and visualizing your Remnawave infrastructure"
|
||||
icon="📊"
|
||||
columns={2}
|
||||
>
|
||||
<ProjectCard
|
||||
id="xray-checker"
|
||||
title="Xray Checker"
|
||||
description="Xray Checker is a tool for monitoring proxy server availability with support for VLESS, VMess, Trojan, and Shadowsocks protocols. It automatically tests connections through Xray Core and provides metrics for Prometheus, as well as API endpoints for integration with various monitoring systems."
|
||||
author="kutovoys"
|
||||
authorLink="https://github.com/kutovoys"
|
||||
image="/awesome/xray-checker.webp"
|
||||
githubRepo="kutovoys/xray-checker"
|
||||
links={{
|
||||
github: 'https://github.com/kutovoys/xray-checker',
|
||||
docs: 'https://xray-checker.kutovoy.dev/',
|
||||
telegram: 'https://t.me/+FvF4gjr_JLZiOGEy'
|
||||
}}
|
||||
>
|
||||
<XrayCheckerGuide />
|
||||
</ProjectCard>
|
||||
<ProjectCard
|
||||
id="whitebox"
|
||||
title="Whitebox"
|
||||
description="A Prometheus exporter that provides availability monitoring of external VPN services powered by VMESS, VLESS, TROJAN, WireGuard, AmneziaWG and Shadowsocks."
|
||||
author="quyxishi"
|
||||
authorLink="https://github.com/quyxishi"
|
||||
image="/awesome/whitebox-hemera-view.webp"
|
||||
githubRepo="quyxishi/whitebox"
|
||||
links={{
|
||||
github: 'https://github.com/quyxishi/whitebox'
|
||||
}}
|
||||
>
|
||||
<WhiteboxGuide />
|
||||
</ProjectCard>
|
||||
</CategorySection>
|
||||
|
||||
<CategorySection
|
||||
id="commerce"
|
||||
title="Commerce"
|
||||
description="Telegram bots and mini apps made for commerce with Remnawave."
|
||||
icon="📦"
|
||||
columns={2}
|
||||
>
|
||||
<ProjectCard
|
||||
id="remnawave-telegram-shop-bot"
|
||||
title="RWP Shop"
|
||||
description="A Telegram bot for selling subscriptions with integration to Remnawave. This service allows users to purchase and manage subscriptions through Telegram with multiple payment system options."
|
||||
author="jolymmiles"
|
||||
authorLink="https://github.com/Jolymmiles"
|
||||
image="/awesome/rwp-shop-image.webp"
|
||||
githubRepo="Jolymmiels/remnawave-telegram-shop"
|
||||
links={{
|
||||
github: 'https://github.com/Jolymmiels/remnawave-telegram-shop',
|
||||
docs: 'https://docs.remnawavebot.dev',
|
||||
private: 'https://me.remnawavebot.dev/',
|
||||
telegram: 'https://t.me/remnawavetelegramshop'
|
||||
}}
|
||||
featured={true}
|
||||
/>
|
||||
<ProjectCard
|
||||
id="remnawave-bedolaga-bot"
|
||||
title="Remnawave Bedolaga Bot"
|
||||
description="Modern Telegram bot for automating VPN business through Remnawave API. Full-featured solution with user management, multi-channel payments, referral system, detailed analytics, Web API, Web Cabinet and Telegram Mini App integration."
|
||||
author="Fr1ngg"
|
||||
authorLink="https://github.com/Fr1ngg"
|
||||
image="/awesome/bedolaga.webp"
|
||||
githubRepo="Fr1ngg/remnawave-bedolaga-telegram-bot"
|
||||
links={{
|
||||
github: 'https://github.com/Fr1ngg/remnawave-bedolaga-telegram-bot',
|
||||
telegram: 'https://t.me/+wTdMtSWq8YdmZmVi'
|
||||
}}
|
||||
featured={true}
|
||||
>
|
||||
<RemnavaweBedolagaBotGuide />
|
||||
</ProjectCard>
|
||||
|
||||
<ProjectCard
|
||||
id="remnashop"
|
||||
title="Remnashop"
|
||||
description="A modern Telegram bot for selling and managing subscriptions with maximum flexibility. Create trial, free, or paid plans, restrict access for specific users or groups, set limits, adjust prices, and assign plans to different nodes — all through an intuitive plan configurator."
|
||||
author="snoups"
|
||||
authorLink="https://github.com/snoups"
|
||||
image="/awesome/remnashop.webp"
|
||||
githubRepo="snoups/remnashop"
|
||||
links={{
|
||||
github: 'https://github.com/snoups/remnashop',
|
||||
telegram: 'https://t.me/remna_shop'
|
||||
}}
|
||||
>
|
||||
<RemnashopGuide />
|
||||
</ProjectCard>
|
||||
|
||||
</CategorySection>
|
||||
|
||||
<CategorySection
|
||||
id="auto-installers"
|
||||
title="Auto-installers"
|
||||
description="Automated installation, configuration, and deployment tools for Remnawave infrastructure."
|
||||
icon="🚀 "
|
||||
columns={2}
|
||||
>
|
||||
<ProjectCard
|
||||
id="remnawave-reverse-proxy"
|
||||
title="Remnawave Reverse Proxy"
|
||||
description="Server Setup Using NGINX Reverse Proxy. This script is designed to streamline the setup of a reverse proxy server using NGINX and Xray, as well as to automate the installation of the Remnawave control panel and node. In this configuration, Xray operates directly on port 443, forwarding traffic through a socket that NGINX listens to."
|
||||
author="eGamesAPI"
|
||||
authorLink="https://github.com/eGamesAPI"
|
||||
image="/awesome/remnawave-reverse-proxy.webp"
|
||||
githubRepo="eGamesAPI/remnawave-reverse-proxy"
|
||||
links={{
|
||||
github: 'https://github.com/eGamesAPI/remnawave-reverse-proxy',
|
||||
docs: 'https://wiki.egam.es',
|
||||
telegram: 'https://t.me/+G8GtPf9dW9FlMWVi'
|
||||
}}
|
||||
featured={true}
|
||||
>
|
||||
<RemnawaveReverseProxyGuide />
|
||||
</ProjectCard>
|
||||
<ProjectCard
|
||||
id="remnawave-management-scripts"
|
||||
title="Remnawave Management Scripts"
|
||||
description="Comprehensive bash scripts for Remnawave Panel, Remnawave Node, and Reality Selfsteal with full automation support. Features Docker integration, intelligent backup/restore system with version checking, advanced monitoring, and complete lifecycle management."
|
||||
author="DigneZzZ"
|
||||
authorLink="https://github.com/DigneZzZ"
|
||||
image="/awesome/remnawave-script.webp"
|
||||
githubRepo="DigneZzZ/remnawave-scripts"
|
||||
links={{
|
||||
github: 'https://github.com/DigneZzZ/remnawave-scripts'
|
||||
}}
|
||||
>
|
||||
<RemnawaveManagementScriptsGuide />
|
||||
</ProjectCard>
|
||||
<ProjectCard
|
||||
id="remnasetup"
|
||||
title="RemnaSetup"
|
||||
description="Universal script for automatic installation, configuration, and updating of Remnawave and Remnanode infrastructure. Includes installation of the control panel, node, subscription page, Caddy setup, Tblocker, BBR, WARP, and an automatic backup system with Telegram integration."
|
||||
author="Capybara-z"
|
||||
authorLink="https://github.com/Capybara-z"
|
||||
image="/awesome/remnasetup.webp"
|
||||
githubRepo="Capybara-z/RemnaSetup"
|
||||
links={{
|
||||
github: 'https://github.com/Capybara-z/RemnaSetup'
|
||||
}}
|
||||
>
|
||||
<RemnasetupGuide />
|
||||
</ProjectCard>
|
||||
<ProjectCard
|
||||
id="ansible-playbook"
|
||||
title="Ansible playbook for Install Remnawave"
|
||||
description="This project helps install Remnawave via Ansible."
|
||||
author="iphizic"
|
||||
authorLink="https://github.com/iphizic"
|
||||
image="/awesome/ansible.webp"
|
||||
githubRepo="iphizic/remna-playbook"
|
||||
links={{
|
||||
github: 'https://github.com/iphizic/remna-playbook'
|
||||
}}
|
||||
>
|
||||
<AnsiblePlaybookGuide />
|
||||
</ProjectCard>
|
||||
</CategorySection>
|
||||
|
||||
<CategorySection
|
||||
id="backup-restore"
|
||||
title="Backup & Restore"
|
||||
description="Tools for backing up and restoring your Remnawave database and configurations"
|
||||
icon="💾"
|
||||
columns={1}
|
||||
>
|
||||
<ProjectCard
|
||||
id="remnawave-backup-restore"
|
||||
title="Remnawave Backup & Restore"
|
||||
description="The script automates backups and performs a restore of the Remnawave database."
|
||||
author="distillium"
|
||||
authorLink="https://github.com/distillium"
|
||||
image="/awesome/remnawave-backup-restore.webp"
|
||||
githubRepo="distillium/remnawave-backup-restore"
|
||||
links={{
|
||||
github: 'https://github.com/distillium/remnawave-backup-restore'
|
||||
}}
|
||||
>
|
||||
<RemnawaveBackupRestoreGuide />
|
||||
</ProjectCard>
|
||||
<ProjectCard
|
||||
id="remnawave-backuper"
|
||||
title="Backuper"
|
||||
description="Automated backup solution with unlimited size support and multi-platform delivery. Supports Gmail, Telegram, and Discord with password protection and Telegram topic integration."
|
||||
author="erfjab"
|
||||
authorLink="https://github.com/erfjab"
|
||||
image="/awesome/remnawave-backuper.webp"
|
||||
githubRepo="erfjab/Backuper"
|
||||
links={{
|
||||
github: 'https://github.com/erfjab/Backuper'
|
||||
}}
|
||||
>
|
||||
<RemnawaveBackuperGuide />
|
||||
</ProjectCard>
|
||||
</CategorySection>
|
||||
|
||||
<CategorySection
|
||||
id="misc"
|
||||
title="Misc"
|
||||
description="Utilities, tools, and integrations that don't fit into other categories."
|
||||
icon="🔧"
|
||||
columns={2}
|
||||
>
|
||||
<ProjectCard
|
||||
id="remnawave-telegram-mini-app"
|
||||
title="Remnawave Telegram Subscription Mini App"
|
||||
description="This is a Telegram Subscription Mini App that allows users to view their subscriptions directly through Telegram. As a requirement for using the page, the Telegram ID must be set in the user's profile to ensure proper identification and linking of subscriptions."
|
||||
author="maposia"
|
||||
authorLink="https://github.com/maposia"
|
||||
image="/awesome/remnawave-telegram-sub-mini-app.webp"
|
||||
githubRepo="maposia/remnawave-telegram-sub-mini-app"
|
||||
links={{
|
||||
github: 'https://github.com/maposia/remnawave-telegram-sub-mini-app',
|
||||
telegram: 'https://t.me/reway_apps'
|
||||
}}
|
||||
>
|
||||
<RemnavaweTelegramMiniAppGuide />
|
||||
</ProjectCard>
|
||||
<ProjectCard
|
||||
id="remnawave-cloudflare-nodes"
|
||||
title="Cloudflare Nodes"
|
||||
description="Automatically manage Cloudflare DNS records based on Remnawave node health status."
|
||||
author="hteppl"
|
||||
authorLink="https://github.com/hteppl"
|
||||
image="/awesome/remnawave-cloudflare-nodes.webp"
|
||||
githubRepo="hteppl/remnawave-cloudflare-nodes"
|
||||
links={{
|
||||
github: 'https://github.com/hteppl/remnawave-cloudflare-nodes',
|
||||
telegram: 'https://t.me/+oWSs_u-Wg2piNDIy'
|
||||
}}
|
||||
>
|
||||
<RemnawaveCloudflareNodes />
|
||||
</ProjectCard>
|
||||
<ProjectCard
|
||||
id="warp-native-installer"
|
||||
title="WARP Native Installer"
|
||||
description="This script installs Cloudflare WARP in 'native' mode via WireGuard, without using warp-cli. Automates package installation, wgcf configuration, and enables autorun. Available as both shell script and Ansible role."
|
||||
author="distillium & TheMelbine"
|
||||
authorLink="https://github.com/distillium"
|
||||
image="/awesome/warp-native.webp"
|
||||
githubRepo="distillium/warp-native"
|
||||
links={{
|
||||
github: 'https://github.com/distillium/warp-native'
|
||||
}}
|
||||
>
|
||||
<WarpNativeInstallerGuide />
|
||||
</ProjectCard>
|
||||
<ProjectCard
|
||||
id="geo-file-viewer"
|
||||
title="Geo File Viewer"
|
||||
description="A utility for viewing the contents of geoip and geofile (.dat) files in the v2fly format."
|
||||
image="/awesome/geofileviewer.webp"
|
||||
links={{
|
||||
website: 'https://jomertix.github.io/geofileviewer'
|
||||
}}
|
||||
/>
|
||||
|
||||
<ProjectCard
|
||||
id="remnawave-admin"
|
||||
title="Remnawave Admin Web + Bot"
|
||||
description="Web panel and telegram bot for managing Remnawave panel. Features user/node/host management, billing, anti-abuse system with multi-factor connection analysis, built-in mail server, webhook notifications, and an interactive web dashboard with geo-map visualization."
|
||||
author="Case211"
|
||||
authorLink="https://github.com/Case211"
|
||||
image="/awesome/remnawave-admin.webp"
|
||||
githubRepo="Case211/remnawave-admin"
|
||||
links={{
|
||||
github: 'https://github.com/Case211/remnawave-admin',
|
||||
telegram: 'https://t.me/remnawave_admin'
|
||||
}}
|
||||
featured={true}
|
||||
/>
|
||||
|
||||
<ProjectCard
|
||||
id="mcp-remnawave"
|
||||
title="MCP Remnawave"
|
||||
description="An MCP server for managing Remnawave panel through AI assistants like Claude Desktop, Cursor, and Windsurf. Provides 51 tools for managing users, nodes, hosts, subscriptions, squads, and HWID devices, along with real-time panel statistics and guided prompts for common tasks."
|
||||
author="TrackLine"
|
||||
authorLink="https://github.com/TrackLine"
|
||||
image="/awesome/mcp-remnawave.webp"
|
||||
githubRepo="TrackLine/mcp-remnawave"
|
||||
links={{
|
||||
github: 'https://github.com/TrackLine/mcp-remnawave'
|
||||
}}
|
||||
>
|
||||
<McpRemnawaveGuide />
|
||||
</ProjectCard>
|
||||
|
||||
</CategorySection>
|
||||
|
||||
<CategorySection
|
||||
id="clients"
|
||||
title="Clients"
|
||||
description="Proxy clients based on Remnawave functionality"
|
||||
icon="🖥️"
|
||||
columns={2}
|
||||
>
|
||||
<ProjectCard
|
||||
id="koala-clash"
|
||||
title="Koala-Clash (fork of Clash Verge Rev)"
|
||||
description="Koala-Clash is a desktop (Windows, Linux, macOS) client for Mihomo. A Clash Meta GUI based on Tauri."
|
||||
author="coolcoala"
|
||||
authorLink="https://github.com/coolcoala"
|
||||
image="/awesome/koalaclash.webp"
|
||||
githubRepo="coolcoala/clash-verge-rev-lite"
|
||||
hwidSupported={true}
|
||||
links={{
|
||||
github: 'https://github.com/coolcoala/clash-verge-rev-lite',
|
||||
telegram: 'https://t.me/+WCL__GOFzZJkYjZi'
|
||||
}}
|
||||
/>
|
||||
<ProjectCard
|
||||
id="flclashx"
|
||||
title="FlClashX (fork of FlClash)"
|
||||
description="A fork of the multi-platform (Windows, Android, Linux, macOS) proxy client FlClash based on ClashMeta, simple and easy to use, open source and ad-free."
|
||||
author="pluralplay"
|
||||
authorLink="https://github.com/pluralplay"
|
||||
image="/awesome/flclashx.webp"
|
||||
githubRepo="pluralplay/flclashx"
|
||||
links={{
|
||||
github: 'https://github.com/pluralplay/flclashx',
|
||||
telegram: 'https://t.me/flclashx'
|
||||
}}
|
||||
hwidSupported={true}
|
||||
featured={true}
|
||||
/>
|
||||
<ProjectCard
|
||||
id="prizrakbox"
|
||||
title="Prizrak-Box (fork of Pandora-Box)"
|
||||
description="Prizrak-Box is a desktop (Windows, Linux, macOS) client for Mihomo, supporting subscription management and routing rule configuration.
|
||||
It allows using and overriding routes with custom templates (includes built-in templates relevant for Russia)."
|
||||
author="legiz"
|
||||
authorLink="https://github.com/legiz-ru"
|
||||
image="/awesome/prizrakbox.webp"
|
||||
githubRepo="legiz-ru/Prizrak-Box"
|
||||
hwidSupported={true}
|
||||
links={{
|
||||
github: 'https://github.com/legiz-ru/Prizrak-Box'
|
||||
}}
|
||||
/>
|
||||
<ProjectCard
|
||||
id="flowvy"
|
||||
title="Flowvy (fork of FlClash)"
|
||||
description="Flowvy is a multi-platform (Windows, Android) client based on FlClash, featuring advanced notifications for traffic usage and subscription expiry. It offers a redesigned UI with Russian localization, a new home widget, and supports core setting overrides from the config."
|
||||
author="x_kit_"
|
||||
authorLink="https://github.com/this-xkit/"
|
||||
image="/awesome/flowvy.webp"
|
||||
githubRepo="this-xkit/Flowvy"
|
||||
hwidSupported={true}
|
||||
links={{
|
||||
github: 'https://github.com/this-xkit/Flowvy'
|
||||
}}
|
||||
/>
|
||||
</CategorySection>
|
||||
|
||||
---
|
||||
|
||||
<h2 id="remnafamily">💬 Join the chat list in Telegram</h2>
|
||||
|
||||
### RemnaFamily
|
||||
|
||||
[Join the chat list](https://t.me/addlist/_MNKSbbkAlQ3ZjQy)
|
||||
|
||||
## 🎯 Add Your Project
|
||||
|
||||
Want to showcase your Remnawave-related project? We'd love to see it!
|
||||
|
||||
**Requirements:**
|
||||
|
||||
- ✅ Project must be open source
|
||||
- ✅ Project must be related to Remnawave or useful for Remnawave users
|
||||
|
||||
**How to submit:**
|
||||
|
||||
1. Open a PR on [GitHub](https://github.com/remnawave/panel/blob/main/docs/awesome-remnawave.mdx)
|
||||
2. Make sure the target branch is `main`
|
||||
|
||||
:::tip Making beautiful previews
|
||||
|
||||
1. Make screenshot of your project
|
||||
2. Paste it to https://shots.so
|
||||
3. Select background colors and download image
|
||||
4. Compress it to `webp` format with https://squoosh.app/
|
||||
5. Put it to `static/awesome` directory
|
||||
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
<div
|
||||
style={{
|
||||
textAlign: 'center',
|
||||
marginTop: '4rem',
|
||||
padding: '2rem',
|
||||
borderRadius: '12px'
|
||||
}}
|
||||
>
|
||||
<h3>🌟 Thank you to all contributors!</h3>
|
||||
<p>The Remnawave community thrives because of amazing developers like you.</p>
|
||||
</div>
|
||||
51
docs/awesome-remnawave/_install-guides/ansible-playbook.md
Normal file
@@ -0,0 +1,51 @@
|
||||
### Installation instructions
|
||||
|
||||
#### Clone repo and change dir
|
||||
|
||||
```bash
|
||||
git clone https://github.com/iphizic/remna-playbook.git
|
||||
cd remna-playbook
|
||||
```
|
||||
|
||||
#### Now make Python .env:
|
||||
|
||||
```bash
|
||||
python3 -m venv .env
|
||||
```
|
||||
|
||||
#### Activate .env:
|
||||
|
||||
```bash
|
||||
source .env/bin/activate
|
||||
```
|
||||
|
||||
#### Install Ansible and requirements:
|
||||
|
||||
```bash
|
||||
pip install -r requirements.txt
|
||||
ansible-galaxy install -r requirements.yml
|
||||
```
|
||||
|
||||
#### Make inventory and other vars
|
||||
|
||||
Make inventory like inventory.yml.example in inventory dir
|
||||
In directory group_vars make all.yml like all.yml.example
|
||||
|
||||
#### `Optional` Make some user but not root
|
||||
|
||||
:::warning
|
||||
To run this playbook, the GitHub username must match the username in all.yml
|
||||
:::
|
||||
|
||||
```bash
|
||||
ansible-playbook prepare-playbook.yml -u root -k
|
||||
```
|
||||
|
||||
First question it is root password
|
||||
Second question it is password for the created user
|
||||
|
||||
#### Run install Remnaware:
|
||||
|
||||
```bash
|
||||
ansible-playbook playbook.yml -K
|
||||
```
|
||||
7
docs/awesome-remnawave/_install-guides/mcp-remnawave.md
Normal file
@@ -0,0 +1,7 @@
|
||||
### Features
|
||||
|
||||
- **51 tools** for managing users, nodes, hosts, subscriptions, squads, and HWID devices
|
||||
- **3 resources** for real-time panel statistics, node status, and health checks
|
||||
- **5 guided prompts** for common operational tasks
|
||||
- **Type-safe API** interactions via `@remnawave/backend-contract`
|
||||
- **Docker Ready** — easy deployment with Docker Compose
|
||||
21
docs/awesome-remnawave/_install-guides/remnasetup.md
Normal file
@@ -0,0 +1,21 @@
|
||||
### 🔥 Main Features
|
||||
|
||||
- 📦 Complete Remnawave installation + Subscription page + Caddy
|
||||
- 🌐 Remnanode installation with Caddy, Tblocker, BBR, and WARP
|
||||
- 💾 Backup system with Telegram integration
|
||||
- ♻️ Recovery from local backups and Telegram
|
||||
- 🔄 Automatic component updates
|
||||
|
||||
### Quick Start
|
||||
|
||||
#### Option 1
|
||||
|
||||
```bash
|
||||
bash <(curl -fsSL raw.githubusercontent.com/Capybara-z/RemnaSetup/refs/heads/main/install.sh)
|
||||
```
|
||||
|
||||
#### Option 2
|
||||
|
||||
```bash
|
||||
curl -fsSL https://raw.githubusercontent.com/Capybara-z/RemnaSetup/refs/heads/main/install.sh -o install.sh && chmod +x install.sh && sudo bash ./install.sh
|
||||
```
|
||||
14
docs/awesome-remnawave/_install-guides/remnashop.md
Normal file
@@ -0,0 +1,14 @@
|
||||
|
||||
* 📦 **Flexible Plans** – Create trial, free, or paid plans with any limits, multi-currency pricing, customizable duration, and assign plans to users or user groups.
|
||||
* 🎟️ **Promocodes** – Reward users with extra days, traffic, plan activation, or discounts.
|
||||
* 📢 **Broadcasts** – Send messages with photos, videos, GIFs, stickers, and HTML formatting. Target by user type and preview before sending.
|
||||
* 🔔 **Notifications** – Custom alerts for users (expiring subscriptions, traffic limits) and system events (bot updates, new users, node status) and more.
|
||||
* 👥 **Referral Program** – Two-level referrals with customizable rewards and detailed statistics.
|
||||
* 💳 **Flexible Payments** – Supports multiple gateways with configurable setup, test payments, and display order.
|
||||
* 📱 **Device Management** – Users can manage connected devices within limits.
|
||||
* 🏷️ **Discounts** – Personal and next-purchase discounts.
|
||||
* 🔐 **Access Modes** – Full, open, invite-only, or restricted access with automatic notifications and conditional rules.
|
||||
* 📈 **Ad Links & Analytics** – Track user acquisition, traffic sources, and view detailed statistics.
|
||||
* 👤 **User Management** – Full user editor with subscription, roles, stats, plan access, device management.
|
||||
* 🔄 **Sync & Migration** – Synchronization with panel and seamless migration from other bots.
|
||||
* 🌐 **Internationalization** – Multi-language support with locale-specific banners.
|
||||
@@ -0,0 +1,26 @@
|
||||
### Features
|
||||
|
||||
- creating a manual backup and configuring automatic scheduled backups
|
||||
- notifications in Telegram with backup file attached
|
||||
- supports sending backup to Google Drive
|
||||
- restore from backup
|
||||
- backups retention policy (7 days) implemented
|
||||
- quick access from anywhere on the system with the `rw-backup` command
|
||||
|
||||
### Installation
|
||||
|
||||
```bash
|
||||
curl -o ~/backup-restore.sh https://raw.githubusercontent.com/distillium/remnawave-backup-restore/main/backup-restore.sh && chmod +x ~/backup-restore.sh && ~/backup-restore.sh
|
||||
```
|
||||
|
||||
:::danger
|
||||
As a precaution, use the restore function on the same panel version from which the backup was made (or create the backup from the latest panel version).
|
||||
:::
|
||||
|
||||
:::warning
|
||||
This script is designed to perform meaningful maintenance operations on the Remnawave database. Although it has been thoroughly tested, its functions affect the entire database and its components. It is recommended that you carefully follow the script's instructions before executing any commands.
|
||||
:::
|
||||
|
||||
:::tip
|
||||
The script backups and restores only the entire database, as well as the .env and .env-node files (if they exist in the /opt/remnawave/ or /root/remnawave/ directory). The backup and recovery of all other files and configurations are entirely the responsibility of the user.
|
||||
:::
|
||||
14
docs/awesome-remnawave/_install-guides/remnawave-backuper.md
Normal file
@@ -0,0 +1,14 @@
|
||||
### Features
|
||||
|
||||
- Unlimited backup size
|
||||
- 3 platform support [gmail, telegram, discord]
|
||||
- Password support
|
||||
- Telegram topic support
|
||||
|
||||
|
||||
### Installation
|
||||
|
||||
```bash
|
||||
sudo bash -c "$(curl -sL https://github.com/erfjab/Backuper/raw/master/backuper.sh)"
|
||||
```
|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
### 🔥 Key Features
|
||||
- 💰 **Multi-channel payments** - Telegram Stars, Tribute, YooKassa (SBP + cards), CryptoBot, Heleket, MulenPay, PayPalych (SBP + cards), Platega (cards + SBP), WATA, Freekassa (NSPK SBP + cards), CloudPayments (cards + SBP)
|
||||
- 🎯 **99% automation** - from registration to subscription renewals
|
||||
- 📱 **MiniApp personal cabinet** - web interface for subscription purchase and management
|
||||
- 🆕 **Web Cabinet (Cabinet WebApp)** - new user personal account with JWT authentication, Telegram Login Widget, email login with verification, password reset, and full CORS support
|
||||
- 🎁 **Advanced promo system** - promo codes (balance/days/trial), promo groups, campaigns with automatic bonuses, personal offers
|
||||
- 📊 **Detailed analytics** - complete business overview with statistics and topic notifications
|
||||
- 🛡️ **Enterprise ready** - Python 3.13, AsyncIO, PostgreSQL, Redis, modular architecture
|
||||
- 🔒 **Security** - panel protection via cookie authentication, support for remnawave-reverse-proxy
|
||||
- 🗄️ **Backup system** - automatic backups with Telegram notifications and in-bot restore
|
||||
- 🌐 **Multi-language** - Russian and English with expansion capability
|
||||
- 🔧 **Flexible configuration** - tariff mode, traffic packages, device limits, smart server selection
|
||||
- 🌐 **Web API** - 50+ REST endpoints for external integrations and custom admin panels
|
||||
- 🔄 **Auto-sync** - background synchronization of subscriptions and servers with Remnawave
|
||||
- 🎮 **Contests & games** - daily games with prizes and referral contests
|
||||
- ✔️ **Channel subscription check** - verify channel subscription before access
|
||||
@@ -0,0 +1,9 @@
|
||||
### Features
|
||||
|
||||
- **Automatic Health Monitoring** - Continuously monitors node health status via Remnawave API
|
||||
- **Dynamic DNS Management** - Adds DNS records for healthy nodes, removes records for unhealthy ones
|
||||
- **Auto Zone Discovery** - Automatically discovers Cloudflare zone IDs from domain names
|
||||
- **Multi-Domain Support** - Manage multiple domains with multiple DNS zones each
|
||||
- **Telegram Notifications** - Real-time alerts for node status changes, DNS updates, and critical events
|
||||
- **Configurable Intervals** - Set custom health check intervals
|
||||
- **Docker Ready** - Easy deployment with Docker and Docker Compose
|
||||
@@ -0,0 +1,136 @@
|
||||
### 📦 Key Features
|
||||
|
||||
- 🚀 **One-line installation** for Panel, Node, and Selfsteal configurations
|
||||
- 🎛️ **Interactive menus** with real-time status monitoring and guided operations
|
||||
- 💾 **Smart backup system** with version compatibility checking and safety rollbacks
|
||||
- 🔄 **Complete lifecycle management** - install, update, backup, restore, uninstall
|
||||
- 🎯 **Reality masking** with 11 AI-generated website templates
|
||||
|
||||
### Quick Install Commands
|
||||
|
||||
#### Remnawave Panel (v3.5.5+)
|
||||
|
||||
```bash
|
||||
bash <(curl -Ls https://github.com/DigneZzZ/remnawave-scripts/raw/main/remnawave.sh) @ install
|
||||
```
|
||||
|
||||
#### Remnawave Node (v3.1.2+)
|
||||
|
||||
```bash
|
||||
bash <(curl -Ls https://github.com/DigneZzZ/remnawave-scripts/raw/main/remnanode.sh) @ install
|
||||
```
|
||||
|
||||
#### Reality Selfsteal (v2.1.3+)
|
||||
|
||||
```bash
|
||||
bash <(curl -Ls https://github.com/DigneZzZ/remnawave-scripts/raw/main/selfsteal.sh) @ install
|
||||
```
|
||||
|
||||
:::info Options
|
||||
|
||||
- Add `--dev` for development version
|
||||
- Add `--name customname` for custom directory (default: `/opt/remnawave`, `/opt/remnanode`)
|
||||
:::
|
||||
|
||||
#### For existing installations
|
||||
|
||||
Use `install-script` to add CLI wrapper only:
|
||||
|
||||
```bash
|
||||
bash <(curl -Ls https://github.com/DigneZzZ/remnawave-scripts/raw/main/remnawave.sh) @ install-script
|
||||
```
|
||||
|
||||
```bash
|
||||
bash <(curl -Ls https://github.com/DigneZzZ/remnawave-scripts/raw/main/remnanode.sh) @ install-script
|
||||
```
|
||||
|
||||
### Available CLI Commands
|
||||
|
||||
**Installation & Management:**
|
||||
|
||||
- `install`, `update`, `uninstall`
|
||||
- `install-script`, `uninstall-script`
|
||||
|
||||
**Service Control:**
|
||||
|
||||
- `up`, `down`, `restart`, `status`, `logs`
|
||||
|
||||
**Node-specific Commands:**
|
||||
|
||||
- `core-update` - Manual Update/Install Xray-core to latest version
|
||||
- `xray-log-out`, `xray-log-err` - View Xray logs
|
||||
- `setup-logs` - Configure log rotation
|
||||
|
||||
**Configuration:**
|
||||
|
||||
- `edit`, `edit-env`, `console` (Panel only)
|
||||
|
||||
**Interactive Menus:**
|
||||
|
||||
- Run `remnawave`, `remnanode`, or `selfsteal` without arguments for interactive menu
|
||||
- Real-time status monitoring and resource usage
|
||||
- Step-by-step guided operations
|
||||
|
||||
**Backup & Restore (Panel):**
|
||||
|
||||
- `backup` - Create manual backup
|
||||
- `schedule` - Configure automated backups
|
||||
- `restore` - Restore from backup archive
|
||||
|
||||
**Reality Selfsteal:**
|
||||
|
||||
- Choose from 11 AI-generated website templates
|
||||
- Automatic SSL certificate management by Caddy
|
||||
- DNS validation before start
|
||||
|
||||
Run `remnawave help`, `remnanode help`, or `selfsteal help` for detailed usage.
|
||||
|
||||
### 💾 Intelligent Backup & Restore System
|
||||
|
||||
**🔄 Smart Backup Features:**
|
||||
|
||||
- **Version-aware backups** with compatibility checking
|
||||
- **Safety restore** with automatic rollback protection
|
||||
- **Scheduled automation** with cron integration
|
||||
- **Telegram notifications** with file delivery and alerts
|
||||
- **Cross-server migration** support with detailed instructions
|
||||
- **Compressed archives** with unified structure
|
||||
|
||||
**📦 What's Backed Up:**
|
||||
|
||||
- PostgreSQL database as `db_backup.sql`
|
||||
- Configuration files: `docker-compose.yml`, `.env`, `app-config.json`
|
||||
- Optional: full directory backup with selective restore
|
||||
|
||||
**🎯 Quick Commands:**
|
||||
|
||||
```bash
|
||||
remnawave backup # Create instant backup
|
||||
remnawave schedule # Setup automated backups
|
||||
remnawave restore # Intelligent restore with version checks
|
||||
```
|
||||
|
||||
**🛡️ Safety Features:**
|
||||
|
||||
- Automatic version compatibility verification
|
||||
- Safety backup before restore operations
|
||||
- Rollback capability if restore fails
|
||||
- Real-time status monitoring during operations
|
||||
|
||||
**📋 Restore Options:**
|
||||
|
||||
- Full restore (replace all files and database)
|
||||
- Database-only restore (keep existing files)
|
||||
- Custom directory restoration
|
||||
- Manual restore commands included in each backup archive
|
||||
|
||||
**Legacy Standalone Scripts:**
|
||||
|
||||
Available for users who need legacy standalone backup/restore tools:
|
||||
|
||||
- [remnawave-backup.sh](https://github.com/DigneZzZ/remnawave-scripts/raw/main/remnawave-backup.sh) - Standalone backup script
|
||||
- [restore.sh](https://github.com/DigneZzZ/remnawave-scripts/raw/main/restore.sh) - Standalone restore script
|
||||
|
||||
📦 Full info, updates, and examples: [**remnawave-scripts**](https://github.com/DigneZzZ/remnawave-scripts)
|
||||
|
||||
Project: [GIG.ovh](https://gig.ovh)
|
||||
@@ -0,0 +1,19 @@
|
||||
### Installation Guidelines
|
||||
|
||||
:::warning
|
||||
Please read the [Installation Guidelines](https://github.com/eGamesAPI/remnawave-reverse-proxy/blob/main/README.md) or the [wiki](https://wiki.egam.es) before proceeding with the installation.
|
||||
:::
|
||||
|
||||
### Installation
|
||||
|
||||
```bash
|
||||
bash <(curl -Ls https://raw.githubusercontent.com/eGamesAPI/remnawave-reverse-proxy/refs/heads/main/install_remnawave.sh)
|
||||
```
|
||||
|
||||
### Features
|
||||
|
||||
- Support for automatic configuration updates via subscription
|
||||
- NGINX reverse proxy setup in combination with Xray
|
||||
- Cloudflare SSL certificates with automatic renewal
|
||||
- UFW setup for access management
|
||||
- BBR optimization for TCP connections
|
||||
136
docs/awesome-remnawave/_install-guides/remnawave-scripts.md
Normal file
@@ -0,0 +1,136 @@
|
||||
### 📦 Key Features
|
||||
|
||||
- 🚀 **One-line installation** for Panel, Node, and Selfsteal configurations
|
||||
- 🎛️ **Interactive menus** with real-time status monitoring and guided operations
|
||||
- 💾 **Smart backup system** with version compatibility checking and safety rollbacks
|
||||
- 🔄 **Complete lifecycle management** - install, update, backup, restore, uninstall
|
||||
- 🎯 **Reality masking** with 11 AI-generated website templates
|
||||
|
||||
### Quick Install Commands
|
||||
|
||||
#### Remnawave Panel (v3.5.5+)
|
||||
|
||||
```bash
|
||||
bash <(curl -Ls https://github.com/DigneZzZ/remnawave-scripts/raw/main/remnawave.sh) @ install
|
||||
```
|
||||
|
||||
#### Remnawave Node (v3.1.2+)
|
||||
|
||||
```bash
|
||||
bash <(curl -Ls https://github.com/DigneZzZ/remnawave-scripts/raw/main/remnanode.sh) @ install
|
||||
```
|
||||
|
||||
#### Reality Selfsteal (v2.1.3+)
|
||||
|
||||
```bash
|
||||
bash <(curl -Ls https://github.com/DigneZzZ/remnawave-scripts/raw/main/selfsteal.sh) @ install
|
||||
```
|
||||
|
||||
:::info Options
|
||||
|
||||
- Add `--dev` for development version
|
||||
- Add `--name customname` for custom directory (default: `/opt/remnawave`, `/opt/remnanode`)
|
||||
:::
|
||||
|
||||
#### For existing installations
|
||||
|
||||
Use `install-script` to add CLI wrapper only:
|
||||
|
||||
```bash
|
||||
bash <(curl -Ls https://github.com/DigneZzZ/remnawave-scripts/raw/main/remnawave.sh) @ install-script
|
||||
```
|
||||
|
||||
```bash
|
||||
bash <(curl -Ls https://github.com/DigneZzZ/remnawave-scripts/raw/main/remnanode.sh) @ install-script
|
||||
```
|
||||
|
||||
### Available CLI Commands
|
||||
|
||||
**Installation & Management:**
|
||||
|
||||
- `install`, `update`, `uninstall`
|
||||
- `install-script`, `uninstall-script`
|
||||
|
||||
**Service Control:**
|
||||
|
||||
- `up`, `down`, `restart`, `status`, `logs`
|
||||
|
||||
**Node-specific Commands:**
|
||||
|
||||
- `core-update` - Manual Update/Install Xray-core to latest version
|
||||
- `xray-log-out`, `xray-log-err` - View Xray logs
|
||||
- `setup-logs` - Configure log rotation
|
||||
|
||||
**Configuration:**
|
||||
|
||||
- `edit`, `edit-env`, `console` (Panel only)
|
||||
|
||||
**Interactive Menus:**
|
||||
|
||||
- Run `remnawave`, `remnanode`, or `selfsteal` without arguments for interactive menu
|
||||
- Real-time status monitoring and resource usage
|
||||
- Step-by-step guided operations
|
||||
|
||||
**Backup & Restore (Panel):**
|
||||
|
||||
- `backup` - Create manual backup
|
||||
- `schedule` - Configure automated backups
|
||||
- `restore` - Restore from backup archive
|
||||
|
||||
**Reality Selfsteal:**
|
||||
|
||||
- Choose from 11 AI-generated website templates
|
||||
- Automatic SSL certificate management by Caddy
|
||||
- DNS validation before start
|
||||
|
||||
Run `remnawave help`, `remnanode help`, or `selfsteal help` for detailed usage.
|
||||
|
||||
### 💾 Intelligent Backup & Restore System
|
||||
|
||||
**🔄 Smart Backup Features:**
|
||||
|
||||
- **Version-aware backups** with compatibility checking
|
||||
- **Safety restore** with automatic rollback protection
|
||||
- **Scheduled automation** with cron integration
|
||||
- **Telegram notifications** with file delivery and alerts
|
||||
- **Cross-server migration** support with detailed instructions
|
||||
- **Compressed archives** with unified structure
|
||||
|
||||
**📦 What's Backed Up:**
|
||||
|
||||
- PostgreSQL database as `db_backup.sql`
|
||||
- Configuration files: `docker-compose.yml`, `.env`, `app-config.json`
|
||||
- Optional: full directory backup with selective restore
|
||||
|
||||
**🎯 Quick Commands:**
|
||||
|
||||
```bash
|
||||
remnawave backup # Create instant backup
|
||||
remnawave schedule # Setup automated backups
|
||||
remnawave restore # Intelligent restore with version checks
|
||||
```
|
||||
|
||||
**🛡️ Safety Features:**
|
||||
|
||||
- Automatic version compatibility verification
|
||||
- Safety backup before restore operations
|
||||
- Rollback capability if restore fails
|
||||
- Real-time status monitoring during operations
|
||||
|
||||
**📋 Restore Options:**
|
||||
|
||||
- Full restore (replace all files and database)
|
||||
- Database-only restore (keep existing files)
|
||||
- Custom directory restoration
|
||||
- Manual restore commands included in each backup archive
|
||||
|
||||
**Legacy Standalone Scripts:**
|
||||
|
||||
Available for users who need legacy standalone backup/restore tools:
|
||||
|
||||
- [remnawave-backup.sh](https://github.com/DigneZzZ/remnawave-scripts/raw/main/remnawave-backup.sh) - Standalone backup script
|
||||
- [restore.sh](https://github.com/DigneZzZ/remnawave-scripts/raw/main/restore.sh) - Standalone restore script
|
||||
|
||||
📦 Full info, updates, and examples: [**remnawave-scripts**](https://github.com/DigneZzZ/remnawave-scripts)
|
||||
|
||||
Project: [GIG.ovh](https://gig.ovh)
|
||||
@@ -0,0 +1,100 @@
|
||||
### Features
|
||||
|
||||
- View your subscriptions in the mini app
|
||||
- Multi-language support (English, Russian)
|
||||
|
||||
### Environment Variables
|
||||
|
||||
The application requires the following environment variables to be set:
|
||||
|
||||
| Variable | Description |
|
||||
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `REMNAWAVE_PANEL_URL` | Remnawave Panel URL, can be `http://remnawave:3000` or `https://panel.example.com` |
|
||||
| `REMNAWAVE_TOKEN` | Authentication token for Remnawave API |
|
||||
| `BUY_LINK` | The URL for purchase actions |
|
||||
| `CRYPTO_LINK` | Allows using encrypted links (currently supported Happ application) |
|
||||
| `REDIRECT_LINK` | Allows you to specify a **custom redirect page URL** for deep links. Useful for handling protocols like `v2box://` in Telegram Desktop (Windows). For more details and examples, see [Telegram Deep Link Redirect](https://github.com/maposia/redirect-page/tree/main) |
|
||||
| `AUTH_API_KEY` | If you use "Caddy with security" or TinyAuth for Nginx addon, you can place here X-Api-Key, which will be applied to requests to Remnawave Panel. |
|
||||
| `FORCE_SNOWFLAKES` | Allows snowfall on main page |
|
||||
### Install and Run
|
||||
|
||||
#### 1. Create a new directory for the mini app
|
||||
|
||||
```bash
|
||||
mkdir /opt/remnawave-telegram-sub-mini-app && cd /opt/remnawave-telegram-sub-mini-app
|
||||
```
|
||||
|
||||
#### 2. Download the sample environment variables
|
||||
|
||||
```bash
|
||||
curl -o .env https://raw.githubusercontent.com/maposia/remnawave-telegram-mini-bot/refs/heads/main/.env.example
|
||||
```
|
||||
|
||||
#### 3. Configure the environment variables
|
||||
|
||||
```bash
|
||||
nano .env
|
||||
```
|
||||
|
||||
#### 4. Create docker-compose.yml file
|
||||
|
||||
```bash
|
||||
nano docker-compose.yml
|
||||
```
|
||||
|
||||
**Example below:**
|
||||
|
||||
```yaml
|
||||
services:
|
||||
remnawave-mini-app:
|
||||
image: ghcr.io/maposia/remnawave-telegram-sub-mini-app:latest
|
||||
container_name: remnawave-telegram-mini-app
|
||||
hostname: remnawave-telegram-mini-app
|
||||
env_file:
|
||||
- .env
|
||||
restart: always
|
||||
# volumes:
|
||||
# - ./app-config.json:/app/public/assets/app-config.json
|
||||
ports:
|
||||
- '127.0.0.1:3020:3020'
|
||||
# networks:
|
||||
# - remnawave-network
|
||||
|
||||
#networks:
|
||||
# remnawave-network:
|
||||
# name: remnawave-network
|
||||
# driver: bridge
|
||||
# external: true
|
||||
```
|
||||
|
||||
Uncomment if you want to use your own template downloaded from the Remnawave panel.
|
||||
P.S. File must be placed in the same directory as this `docker-compose.yml` file
|
||||
|
||||
```yaml
|
||||
volumes:
|
||||
- ./app-config.json:/app/public/assets/app-config.json
|
||||
```
|
||||
|
||||
Uncomment if you want to use local connection via single network in docker
|
||||
|
||||
```yaml
|
||||
networks:
|
||||
- remnawave-network
|
||||
|
||||
networks:
|
||||
remnawave-network:
|
||||
name: remnawave-network
|
||||
driver: bridge
|
||||
external: true
|
||||
```
|
||||
|
||||
#### 5. Run containers
|
||||
|
||||
```bash
|
||||
docker compose up -d && docker compose logs -f
|
||||
```
|
||||
|
||||
#### 6. Access the mini app
|
||||
|
||||
Mini app is now running on `http://127.0.0.1:3020`
|
||||
Now we are ready to move on to Reverse Proxy installation.
|
||||
@@ -0,0 +1,98 @@
|
||||
**Script Author:** [distillium](https://github.com/distillium)
|
||||
**Ansible Role Author:** [TheMelbine](https://github.com/TheMelbine)
|
||||
|
||||
### It automates
|
||||
|
||||
- Installing the necessary packages (`wireguard`, `resolvconf`)
|
||||
- Downloading and configuring `wgcf`
|
||||
- Generating and modifying the WireGuard configuration
|
||||
- Connecting and checking status
|
||||
- Enabling autorun of the `warp` interface
|
||||
|
||||
### Installing
|
||||
|
||||
#### Option 1: Shell Script (performed on each desired node)
|
||||
|
||||
```bash
|
||||
bash <(curl -fsSL https://raw.githubusercontent.com/distillium/warp-native/main/install.sh)
|
||||
```
|
||||
|
||||
#### Option 2: Ansible Role (Recommended for automation)
|
||||
|
||||
```bash
|
||||
ansible-galaxy install themelbine.warp_native
|
||||
```
|
||||
|
||||
**Example playbook:**
|
||||
|
||||
```yaml
|
||||
- hosts: warp_servers
|
||||
become: yes
|
||||
roles:
|
||||
- themelbine.warp_native
|
||||
vars:
|
||||
warp_native_state: present
|
||||
warp_native_modify_resolv: true
|
||||
```
|
||||
|
||||
[Ansible Role Github Repository](https://github.com/TheMelbine/ansible-role-warp-native)
|
||||
|
||||
### Templates for Xray configuration
|
||||
|
||||
**Example outbound:**
|
||||
|
||||
```json
|
||||
{
|
||||
"tag": "warp-out",
|
||||
"protocol": "freedom",
|
||||
"settings": {},
|
||||
"streamSettings": {
|
||||
"sockopt": {
|
||||
"interface": "warp",
|
||||
"tcpFastOpen": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Example routing rule:**
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "field",
|
||||
"domain": ["netflix.com", "youtube.com", "twitter.com"],
|
||||
"inboundTag": ["Node-1", "Node-2"],
|
||||
"outboundTag": "warp-out"
|
||||
}
|
||||
```
|
||||
|
||||
### Interface management
|
||||
|
||||
| Operation | Command |
|
||||
| --------------------- | --------------------------------- |
|
||||
| Check service status | `systemctl status wg-quick@warp` |
|
||||
| View interface status | `wg show warp` |
|
||||
| Stop the interface | `systemctl stop wg-quick@warp` |
|
||||
| Start the interface | `systemctl start wg-quick@warp` |
|
||||
| Restart the interface | `systemctl restart wg-quick@warp` |
|
||||
| Disable autorun | `systemctl disable wg-quick@warp` |
|
||||
| Enable autorun | `systemctl enable wg-quick@warp` |
|
||||
|
||||
### Uninstall
|
||||
|
||||
**Shell Script Method:**
|
||||
|
||||
```bash
|
||||
bash <(curl -fsSL https://raw.githubusercontent.com/distillium/warp-native/main/uninstall.sh)
|
||||
```
|
||||
|
||||
**Ansible Role Method:**
|
||||
|
||||
```yaml
|
||||
- hosts: warp_servers
|
||||
become: yes
|
||||
roles:
|
||||
- themelbine.warp_native
|
||||
vars:
|
||||
warp_native_state: absent
|
||||
```
|
||||
138
docs/awesome-remnawave/_install-guides/whitebox.md
Normal file
@@ -0,0 +1,138 @@
|
||||
### 📦 Key Features
|
||||
|
||||
- **Multi-protocol VPN Probing**: Supports probing of external VPN services including VMESS, VLESS, Trojan, Wireguard, AmneziaWG and Shadowsocks.
|
||||
- **RESTful API Service**: Exposes HTTP endpoints for on-demand or scheduled connectivity checks.
|
||||
- **Custom Probe Configuration**: Accepts probe parameters such as connection details, target URLs, response validation rules, and configurable timeouts.
|
||||
- **Prometheus Metrics Integration**: Exposes key probe results as Prometheus metrics.
|
||||
|
||||
### Getting Started
|
||||
|
||||
```shell
|
||||
git clone -b main https://github.com/quyxishi/whitebox
|
||||
cd ./whitebox
|
||||
```
|
||||
|
||||
#### via `docker-compose.yaml`
|
||||
|
||||
```shell
|
||||
sudo docker compose up --build -d
|
||||
```
|
||||
|
||||
#### via `Dockerfile`
|
||||
|
||||
###### Build
|
||||
```shell
|
||||
sudo docker build --tag whitebox .
|
||||
```
|
||||
|
||||
###### Running
|
||||
```shell
|
||||
sudo docker run --rm -d -p 9116:9116 whitebox
|
||||
```
|
||||
|
||||
### Checking the results
|
||||
|
||||
After deploying, you can validate VPN tunnel probing by visiting:
|
||||
```url
|
||||
http://localhost:9116/probe?ctx=<urlencoded_vpn_uri>&target=google.com
|
||||
```
|
||||
|
||||
After that, you will see a Prometheus-style metrics page showing the results of the probe.
|
||||
|
||||
For example, the output may look like:
|
||||
```md
|
||||
# HELP tun_probe_duration_seconds Returns how long the probe took to complete in seconds
|
||||
# TYPE tun_probe_duration_seconds gauge
|
||||
tun_probe_duration_seconds 1.554994
|
||||
# HELP tun_probe_http_content_length_bytes Length of HTTP content response in bytes
|
||||
# TYPE tun_probe_http_content_length_bytes gauge
|
||||
tun_probe_http_content_length_bytes -1
|
||||
# HELP tun_probe_http_duration_seconds Duration of HTTP request by phase, summed over all traces
|
||||
# TYPE tun_probe_http_duration_seconds gauge
|
||||
tun_probe_http_duration_seconds{phase="connect"} 0.1998826
|
||||
tun_probe_http_duration_seconds{phase="processing"} 0.3262475
|
||||
tun_probe_http_duration_seconds{phase="resolve"} 0
|
||||
tun_probe_http_duration_seconds{phase="tls"} 1.2223279
|
||||
tun_probe_http_duration_seconds{phase="transfer"} 0.0064185
|
||||
# HELP tun_probe_http_redirects The number of redirects
|
||||
# TYPE tun_probe_http_redirects gauge
|
||||
tun_probe_http_redirects 1
|
||||
# HELP tun_probe_http_ssl Indicates if SSL was used for the final trace
|
||||
# TYPE tun_probe_http_ssl gauge
|
||||
tun_probe_http_ssl 1
|
||||
# HELP tun_probe_http_status_code Response HTTP status code
|
||||
# TYPE tun_probe_http_status_code gauge
|
||||
tun_probe_http_status_code 200
|
||||
# HELP tun_probe_http_uncompressed_body_length_bytes Length of uncompressed response body in bytes
|
||||
# TYPE tun_probe_http_uncompressed_body_length_bytes gauge
|
||||
tun_probe_http_uncompressed_body_length_bytes 17650
|
||||
# HELP tun_probe_success Displays whether or not the probe over tunnel was a success
|
||||
# TYPE tun_probe_success gauge
|
||||
tun_probe_success 1
|
||||
```
|
||||
|
||||
### Whitebox Configuration
|
||||
|
||||
Refer to the [example configuration](https://github.com/quyxishi/whitebox/blob/main/whitebox.yml) and [code reference](https://github.com/quyxishi/whitebox/blob/main/internal/config/config.go) for implementation details.
|
||||
|
||||
### Prometheus Configuration
|
||||
|
||||
Whitebox follows the [multi-target exporter pattern](https://prometheus.io/docs/guides/multi-target-exporter/).
|
||||
|
||||
###### Example Prometheus configuration:
|
||||
|
||||
```yaml
|
||||
scrape_configs:
|
||||
- job_name: 'whitebox'
|
||||
metrics_path: /probe
|
||||
params:
|
||||
max_redirects: [ '0' ] # Do not follow redirects. (Optional)
|
||||
timeout_ms: [ '5000' ] # Probe timeout in ms. (Optional)
|
||||
file_sd_configs:
|
||||
- files: [ '/etc/prometheus/whitebox-sd-config.yml' ] # File service discovery configurations (targets).
|
||||
relabel_configs:
|
||||
- source_labels: [__address__]
|
||||
target_label: __param_target # 'target' -> '?target=...'.
|
||||
- source_labels: [ctx]
|
||||
target_label: __param_ctx # 'ctx' -> '?ctx=...'.
|
||||
- source_labels: [client]
|
||||
target_label: client # Label all probe's with client id.
|
||||
- source_labels: [protocol]
|
||||
target_label: protocol # Label all probe's with used protocol.
|
||||
- source_labels: [__param_target]
|
||||
target_label: target # Label all probe's with target.
|
||||
- target_label: __address__
|
||||
replacement: 127.0.0.1:9116 # The whitebox real hostname:port.
|
||||
```
|
||||
|
||||
###### Example file service discovery configuration (targets):
|
||||
|
||||
```yaml
|
||||
- targets: [ "https://google.com" ]
|
||||
labels:
|
||||
ctx: "vless://c9f5228c-8870-47bd-a92f-9b38c7c02b08@1.2.3.4:443?type=tcp&encryption=none&security=reality&pbk=DF-3KL2W4RuNB2HgsEDmLqHLvvTTN4_QfwUCUn8Uhy0&fp=firefox&sni=web.max.ru&sid=dc8wq0b47450f9&spx=%2F&flow=xtls-rprx-vision#ring0-raii-idx0"
|
||||
client: "ring0-raii-idx0" # Client unique identifier
|
||||
protocol: "vless" # VPN protocol
|
||||
# You can also add additional labels here:
|
||||
# sni: "web.max.ru"
|
||||
# And then, update relabel_configs in prometheus.yml job's config:
|
||||
# - source_labels: [sni]
|
||||
# target_label: sni
|
||||
- targets: [ "https://cloudflare.com" ]
|
||||
labels:
|
||||
# Wireguard connection must be supplied as: base64-encoded peer .ini config prefixed with 'wireguard://'
|
||||
ctx: "wireguard://W0ludGVyZmFjZV0KUHJpdmF0ZUtleSA9IFNObk5ON0l4YzV0ekNYS2FJNGZXNnEyOFYzbnhGS2YxcmNoYWt4bWdBbHM9CkFkZHJlc3MgPSAxMC4wLjAuMi8zMgpETlMgPSAxLjEuMS4xLCAxLjAuMC4xCk1UVSA9IDE0MjAKCiMgLTEKW1BlZXJdClB1YmxpY0tleSA9IHk2MTdkQ2dNM1g2bEtEanBkdDVhQ3dIWmROWW5OT0FwMFMyanFUbGpmZzA9CkFsbG93ZWRJUHMgPSAwLjAuMC4wLzAsIDo6LzAKRW5kcG9pbnQgPSAxLjIuMy40OjQ0Mw=="
|
||||
client: "wg-raii-idx0"
|
||||
protocol: "wireguard"
|
||||
- targets: [ "https://google.com" ]
|
||||
labels:
|
||||
# AmneziaWG connection with obfuscation parameters (Jc, Jmin, Jmax, S1, S2, H1-H4)
|
||||
# Must be supplied as: base64-encoded peer .ini config prefixed with 'awg://'
|
||||
ctx: "awg://W0ludGVyZmFjZV0KUHJpdmF0ZUtleSA9IFNObk5ON0l4YzN0emxYS2FJNGY4NnEyOFYzbnhGS2YzcmNoYWt4bWdCbHM9CkFkZHJlc3MgPSAxMC4wLjAuMi8zMgpETlMgPSAxLjEuMS4xLCAxLjAuMC4xCk1UVSA9IDE0MjAKSmMgPSAzCkptaW4gPSA1MApKbWF4ID0gMTAwMApTMSA9IDIwClMyID0gNzgKSDEgPSAzOTEzMTI3OApIMiA9IDgzMjEzODE4NQpIMyA9IDE0MzY5NTc4NTcKSDQgPSAxNjM1ODc3NzQ2CgpbUGVlcl0KUHVibGljS2V5ID0geTYxN2RDZ00zWDZsS0RqcGR0NWFHY0FaZE5Zbk5PQXAwUzNqYVRsamZnMD0KQWxsb3dlZElQcyA9IDAuMC4wLjAvMCwgOjovMApFbmRwb2ludCA9IDEuMi4zLjQ6Mjc3ODkK"
|
||||
client: "awg-raii-idx0"
|
||||
protocol: "amneziawg"
|
||||
```
|
||||
|
||||
:::info Tip
|
||||
After all of that, reload Prometheus, visit http://localhost:9090/targets and check for your `whitebox` job.
|
||||
:::
|
||||
20
docs/awesome-remnawave/_install-guides/xray-checker.md
Normal file
@@ -0,0 +1,20 @@
|
||||
### Key Features
|
||||
|
||||
- **Health Monitoring** – Monitor the health of Xray proxy servers with support for various protocols (VLESS, VMess, Trojan, Shadowsocks)
|
||||
- **Automatic Updates** – Automatic proxy configuration updates from subscription URLs with configurable intervals
|
||||
- **Metrics Export** – Prometheus-format metrics export displaying proxy status and latency data
|
||||
- **Web Interface** – Dashboard with dark/light theme modes featuring search, filtering, sorting, and auto-refresh capabilities
|
||||
- **Public Status Page** – Display proxy status without authentication for VPN services
|
||||
- **Web Customization** – Custom logo, favicon, CSS styles, or entire template replacement
|
||||
- **REST API** – REST API with OpenAPI/Swagger documentation
|
||||
- **Flexible Input** – Support for URL subscriptions, Base64-encoded strings, V2Ray/Xray JSON files, JSON arrays, and configuration folders
|
||||
- **Monitoring Integration** – Automatic endpoint generation for integration with monitoring systems (e.g., Uptime-Kuma)
|
||||
- **Latency Simulation** – Test endpoints with configurable latency responses
|
||||
- **Prometheus Pushgateway** – Send metrics to external monitoring platforms
|
||||
- **Multiple Check Methods** – Three verification approaches: IP comparison, HTTP status checks, and file download verification
|
||||
- **Latency Measurement** – TTFB-based (Time To First Byte) measurement for accurate performance data
|
||||
- **Authentication** – Protect metrics and web interface using Basic Authentication
|
||||
- **Multi-Platform Deployment** – Docker container or standalone CLI application options
|
||||
- **Multiple Subscriptions** – Support for multiple subscription URLs simultaneously
|
||||
- **Domain Resolution** – Resolve proxy server domains into IPs and expand configurations
|
||||
- **Reverse Proxy Support** – Configurable base path for URL prefixes behind reverse proxies
|
||||
12
docs/changelog/index.md
Normal file
@@ -0,0 +1,12 @@
|
||||
---
|
||||
sidebar_position: 8
|
||||
title: Changelog
|
||||
hide_title: true
|
||||
hide_table_of_contents: true
|
||||
---
|
||||
|
||||
```mdx-code-block
|
||||
import DocCardList from '@theme/DocCardList';
|
||||
|
||||
<DocCardList/>
|
||||
```
|
||||
152
docs/changelog/remnawave-node.mdx
Normal file
@@ -0,0 +1,152 @@
|
||||
---
|
||||
sidebar_position: 2
|
||||
title: Remnawave Node
|
||||
description: 'Changelog for Remnawave Node'
|
||||
hide_title: true
|
||||
hide_table_of_contents: true
|
||||
---
|
||||
|
||||
# Remnawave Node
|
||||
|
||||
<ReleaseEntry version="2.7.0" date="28 March 2026">
|
||||
|
||||
:::warning
|
||||
Remnawave Panel **v2.7.0** or higher is required.
|
||||
:::
|
||||
|
||||
- Support for new features from [Remnawave Panel v2.7.0](/docs/changelog/remnawave-panel) (plugins, metadata, system stats, etc.)
|
||||
- **Xray Core v26.3.27**
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.6.1" date="24 February 2026">
|
||||
|
||||
- **Xray Core 26.2.6**
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.6.0" date="24 February 2026">
|
||||
|
||||
- Preps for Remnawave Panel v2.6.2 (additional notes will be available later)
|
||||
- **Xray Core 25.12.8**
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.5.5" date="16 February 2026">
|
||||
|
||||
- feat: Rescue CLI (`docker exec -it remnanode cli`)
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.5.4" date="31 January 2026">
|
||||
|
||||
- Fix: [#333](https://github.com/remnawave/panel/issues/333)
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.5.3" date="30 January 2026">
|
||||
|
||||
- Fix: socket naming
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.5.2" date="30 January 2026">
|
||||
|
||||
- Unix sockets for internal communications
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.5.1" date="25 January 2026">
|
||||
|
||||
- Customize Internal ports via env variables: `SUPERVISORD_PORT`, `INTERNAL_REST_PORT`, `XTLS_API_PORT`
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.5.0" date="28 December 2025">
|
||||
|
||||
- Preparations for Panel version 2.5.0
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.3.2" date="19 December 2025">
|
||||
|
||||
- **Xray Core** version bump to **25.12.8**
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.3.1" date="10 December 2025">
|
||||
|
||||
- Add explicit error message if received request from unsupported Remnawave version
|
||||
|
||||
:::warning
|
||||
Remnawave Node **версии 2.3.x и выше** работает только с **Remnawave 2.3.x и выше**.
|
||||
:::
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.3.0" date="7 December 2025">
|
||||
|
||||
- Part of Remnawave v2.3.0 release
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.2.3" date="13 November 2025">
|
||||
|
||||
- New log messages
|
||||
- Respect Level 0 Policies
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.2.2" date="25 October 2025">
|
||||
|
||||
:::warning
|
||||
**APP_PORT**, **SSL_CERT** now is deprecated.
|
||||
|
||||
**APP_PORT** → **NODE_PORT**
|
||||
**SSL_CERT** → **SECRET_KEY**
|
||||
|
||||
Changes not required, but **recommended**. Old values will be automatically converted to new ones, but this behaviour will change in next versions.
|
||||
:::
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.2.1" date="24 October 2025">
|
||||
|
||||
- Small bug fixes
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.2.0" date="22 October 2025">
|
||||
|
||||
- **Xray Core** version bump to **25.10.15**
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.1.7" date="15 September 2025">
|
||||
|
||||
- **Xray Core** version bump to **25.9.11**
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.1.6" date="6 September 2025">
|
||||
|
||||
- **Xray Core** version bump to **25.9.5**
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.1.5" date="3 September 2025">
|
||||
|
||||
- **Xray Core** version bump to **25.8.31**
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.1.4" date="26 August 2025">
|
||||
|
||||
- Add support for force Xray Core restart
|
||||
- Drop several unused packages (execa, others)
|
||||
- Refactor Xray Core version extraction
|
||||
- Add mutex for add/remove users from hot-core config (used by hash checkups)
|
||||
- Add shortcuts for log tailing of Xray Core stdout, stderr logs (`docker exec -it remnanode xlogs`, `docker exec -it remnanode xerros`)
|
||||
- Minor performance optimizations
|
||||
|
||||
</ReleaseEntry>
|
||||
732
docs/changelog/remnawave-panel.mdx
Normal file
@@ -0,0 +1,732 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
title: Remnawave Panel
|
||||
description: 'Changelog for Remnawave Panel'
|
||||
hide_title: true
|
||||
hide_table_of_contents: true
|
||||
---
|
||||
|
||||
# Remnawave Panel
|
||||
|
||||
<ReleaseEntry version="2.7.4" date="30 March 2026">
|
||||
|
||||
### New Features
|
||||
|
||||
- **Extended clients regex** — added `additionalExtendedClientsRegex` to response rule modifications
|
||||
- **Load average tooltip** — node card now shows a tooltip with detailed load average info
|
||||
- **Final Mask** — new host property that allows override `finalMask`
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
- fix: double save in Config Profiles and other sections
|
||||
- fix: reset node basic and system info before querying system stats
|
||||
- fix: allow empty values in response headers validation
|
||||
- fix: empty SNI in Xray Base64
|
||||
- fix: force disconnect incompatible Remnawave Node
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.7.2" date="28 March 2026">
|
||||
|
||||
- hotfix: custom remarks
|
||||
- fix: Hysteria2 Xray-Json generation
|
||||
- fix: base64 serverDescription
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.7.0" date="28 March 2026">
|
||||
|
||||
:::danger
|
||||
**Before updating**, make a full backup of your data (database, configuration files, `.env`). See [Backup & Restore tools](/docs/awesome-remnawave#backup-restore).
|
||||
:::
|
||||
|
||||
:::warning
|
||||
Remnawave Node **v2.7.0** or higher is required.
|
||||
:::
|
||||
|
||||
:::info Update order
|
||||
|
||||
0. **Read the [Action needed](#action-needed) section below** and make a **full backup** of your data before proceeding.
|
||||
1. **Update the panel**:
|
||||
```bash
|
||||
cd /opt/remnawave && docker compose pull remnawave && docker compose down && docker compose up -d && docker compose logs -f
|
||||
```
|
||||
2. **Update the nodes** (on each node server). Make sure `cap_add: NET_ADMIN` is present in your node's `docker-compose.yml` — it is required for plugins and IP management:
|
||||
```yaml
|
||||
cap_add:
|
||||
- NET_ADMIN
|
||||
```
|
||||
Then update:
|
||||
```bash
|
||||
cd /opt/remnanode && docker compose pull remnanode && docker compose down && docker compose up -d && docker compose logs -f
|
||||
```
|
||||
3. **Force restart all nodes**: once all nodes are updated, open the panel and go to **Nodes** → **Management**. Click the spiral button (grape color) and select **Force restart all nodes**.
|
||||
|
||||
:::
|
||||
|
||||
### Action needed
|
||||
|
||||
#### 0. Telegram login — migrated to Generic OAuth2
|
||||
|
||||
The built-in Telegram login widget has been replaced with a [Generic OAuth2](https://core.telegram.org/bots/telegram-login) integration. **Before updating**, disable the Telegram login method in the panel settings and switch to password or another provider.
|
||||
|
||||
If you have already updated and can't log in, use the rescue CLI to enable password authentication:
|
||||
|
||||
```bash
|
||||
docker exec -it remnawave cli
|
||||
```
|
||||
|
||||
After updating, you can re-enable Telegram login by configuring it as a Generic OAuth2 provider.
|
||||
|
||||
#### 1. Telegram notifications — new format
|
||||
|
||||
Remove these variables from your `.env` file:
|
||||
|
||||
```bash title=".env"
|
||||
TELEGRAM_NOTIFY_USERS_CHAT_ID
|
||||
TELEGRAM_NOTIFY_NODES_CHAT_ID
|
||||
TELEGRAM_NOTIFY_CRM_CHAT_ID
|
||||
TELEGRAM_NOTIFY_USERS_THREAD_ID
|
||||
TELEGRAM_NOTIFY_NODES_THREAD_ID
|
||||
TELEGRAM_NOTIFY_CRM_THREAD_ID
|
||||
```
|
||||
|
||||
Replace with new unified format (`chat_id:thread_id`, thread_id is optional):
|
||||
|
||||
```bash title=".env"
|
||||
TELEGRAM_NOTIFY_USERS=change_me
|
||||
TELEGRAM_NOTIFY_NODES=change_me
|
||||
TELEGRAM_NOTIFY_CRM=change_me
|
||||
TELEGRAM_NOTIFY_SERVICE=change_me
|
||||
TELEGRAM_NOTIFY_TBLOCKER=change_me
|
||||
```
|
||||
|
||||
#### 2. Prometheus metrics — breaking changes
|
||||
|
||||
If you use Grafana dashboards or custom alerting based on Prometheus metrics, you **must** update your queries.
|
||||
|
||||
**Renamed metrics** (`nodejs_*` → `process_*`):
|
||||
|
||||
| Old name | New name |
|
||||
| ------------------------------- | ----------------------------- |
|
||||
| `nodejs_heap_used_bytes` | `process_heap_used_bytes` |
|
||||
| `nodejs_heap_total_bytes` | `process_heap_total_bytes` |
|
||||
| `nodejs_active_handlers` | `process_active_handles` |
|
||||
| `nodejs_event_loop_latency_p50` | `process_event_loop_delay_ms` |
|
||||
| `nodejs_event_loop_latency_p95` | `process_event_loop_p99_ms` |
|
||||
|
||||
**Removed metrics**: `nodejs_heap_usage_percent`, `nodejs_active_requests`, `nodejs_cpu_usage_percent`, `nodejs_memory_usage_bytes`, `nodejs_http_req_rate`, `nodejs_http_req_latency_p50`, `nodejs_http_req_latency_p95`
|
||||
|
||||
**New process metrics**: `process_rss_bytes`, `process_external_bytes`, `process_array_buffers_bytes`, `process_uptime_seconds`
|
||||
|
||||
**New node system metrics**: `node_network_rx_bytes_per_sec`, `node_network_tx_bytes_per_sec`, `node_network_rx_bytes_total`, `node_network_tx_bytes_total`, `node_memory_total_bytes`, `node_memory_free_bytes`, `node_uptime_seconds`, `node_cpu_count`, `node_system_info`
|
||||
|
||||
**Reduced label cardinality**: `node_online_users`, `node_status` and all `node_inbound_*`/`node_outbound_*` bandwidth metrics now use only `node_uuid` (+ `tag` for bandwidth). Labels like `node_name`, `node_country_emoji`, `provider_name`, `tags` are moved to dedicated info metrics:
|
||||
|
||||
- `node_basic_info` — static node labels (`node_uuid`, `node_name`, `node_country_emoji`, `provider_name`, `tags`)
|
||||
- `node_system_info` — OS-level labels (`node_uuid`, `arch`, `cpu_model`, `hostname`, `platform`, `release`, `version`)
|
||||
|
||||
Use Prometheus [joins](https://prometheus.io/docs/prometheus/latest/querying/operators/#vector-matching) to enrich queries, e.g.:
|
||||
|
||||
```promql
|
||||
node_online_users * on(node_uuid) group_left(node_name) node_basic_info
|
||||
```
|
||||
|
||||
You can use the updated Grafana dashboard compatible with v2.7.0 metrics: [Remnawave Panel Dashboard](https://grafana.com/grafana/dashboards/25064-remnawave-monitoring-dashboard/)
|
||||
|
||||
#### 3. New optional variable
|
||||
|
||||
```bash title=".env"
|
||||
PANEL_DOMAIN=panel.domain.com
|
||||
```
|
||||
|
||||
Used for generating direct links (e.g. in Telegram notifications with inline buttons).
|
||||
|
||||
|
||||
|
||||
### New features
|
||||
|
||||
- **Node Plugins**: extensible plugin system for nodes — [docs](https://docs.rw/docs/learn/node-plugins)
|
||||
- **Torrent Blocker** — detect and block torrent traffic with configurable block duration, ignore lists, and per-rule-tag targeting. Telegram notifications with inline "View user" button
|
||||
- **Ingress Filter** — block inbound connections from specific IPs via nftables
|
||||
- **Egress Filter** — block outbound connections to specific IPs/ports
|
||||
- **Connection Drop** — drop connections from non-whitelisted IPs
|
||||
- Shared IP lists support (`ext:list_name` format) across plugins
|
||||
- Plugin actions: clone, reorder, execute commands on nodes (block/unblock IPs, recreate tables)
|
||||
- Torrent Blocker Reports: paginated list, statistics (top users, top nodes, 24h summary), truncate
|
||||
- **Metadata API**: store and retrieve custom key-value metadata for users and nodes (`GET/PUT /api/metadata/user/{uuid}`, `/api/metadata/node/{uuid}`)
|
||||
- **Resolve User endpoint** (`POST /api/users/resolve`): resolve a user by any one identifier (uuid, id, shortUuid, or username)
|
||||
- **System Recap** (`GET /api/system/stats/recap`): aggregated system overview — users, nodes, traffic, countries, version, init date
|
||||
- **Traffic Limit Strategy**: new `MONTH_ROLLING` reset period — rolling 30-day traffic window
|
||||
- **Fetch Users IPs**: new IP control endpoint (`POST /api/ip-control/fetch-users-ips/{nodeUuid}`) — fetch per-user IP addresses from a specific node
|
||||
- **IP format change**: IP addresses now returned as objects with `ip` and `lastSeen` fields (instead of plain strings)
|
||||
- **Telegram Bot proxy support**: new optional `TELEGRAM_BOT_PROXY` variable (format: `protocol://user:password@host:port`)
|
||||
- **Custom Telegram Bot API server**: new optional `TELEGRAM_BOT_API_ROOT` variable (default: `https://api.telegram.org`)
|
||||
- **Telegram inline keyboards**: notification messages now support interactive buttons
|
||||
- **Node Bulk Update**: update `countryCode`, `consumptionMultiplier`, `providerUuid`, `tags`, `activePluginUuid` for multiple nodes at once
|
||||
- **Node System Info**: CPU, memory, network, uptime now reported separately from the node model and cached with 30s TTL
|
||||
- **Hysteria2 protocol**: support for Hysteria protocol and transport options (Xray-Json client only)
|
||||
- **KCP transport**: support for KCP network type with TTI and congestion options
|
||||
- **Tunnel protocol**: support for `tunnel` protocol in XRay configuration
|
||||
- **Shadowsocks ciphers**: added `2022-blake3-aes-256-gcm`, `aes-128-gcm`, `aes-256-gcm` cipher methods
|
||||
- **CIDR ranges in plugins**: IP/CIDR validation support in node plugin configurations
|
||||
- **RAW subscription refactor**: the `rawHosts` array in `/api/subscriptions/by-short-uuid/{shortUuid}/raw` is replaced with `resolvedProxyConfigs` — a fully typed structure with discriminated unions for protocol (`vless`, `trojan`, `shadowsocks`), transport (`tcp`, `ws`, `xhttp`, `httpupgrade`, `grpc`, `kcp`), and security (`tls`, `reality`, `none`). Each proxy entry now contains `protocolOptions`, `transportOptions`, `securityOptions`, `streamOverrides`, `mux`, `clientOverrides`, and `metadata` instead of flat fields
|
||||
|
||||
|
||||
|
||||
### Improvements
|
||||
|
||||
- **Docker**: switched from Alpine to Debian-based image (`node:24.14-trixie-slim`)
|
||||
- **Valkey 9**: upgraded from 8.1, now uses Unix socket instead of TCP (default).
|
||||
- **Prometheus metrics refactor**: simplified metric labels (reduced cardinality), renamed `NODEJS_*` → `PROCESS_*`, added node system metrics (network rx/tx, memory, uptime, cpu count)
|
||||
- **Removed `systeminformation`**: system stats now use Node.js `os` module
|
||||
- **Cache refactor**: migrated from `@nestjs/cache-manager` to internal `RawCacheService`, cache TTLs changed from milliseconds to seconds
|
||||
- **Scheduler offsets**: cron jobs staggered by 5–20 minutes to avoid thundering herd at midnight
|
||||
- **OCI labels**: Docker image now includes standard container metadata labels
|
||||
|
||||
|
||||
|
||||
### Removed
|
||||
|
||||
- **Telegram OAuth2** (`POST /api/auth/oauth2/tg/callback`) — migrated to Generic OAuth2 provider
|
||||
- **Outline subscription route** (`GET /api/sub/outline/{shortUuid}/{type}/{encodedTag}`)
|
||||
- **Realtime bandwidth stats** (`GET /api/bandwidth-stats/nodes/realtime`)
|
||||
- **User tracking fields**: `subLastOpenedAt`, `subLastUserAgent` dropped from the database
|
||||
- **Node hardware fields**: `cpuCount`, `cpuModel`, `totalRam` dropped from the database (replaced by Node System Info cache)
|
||||
- **`tgAuthSettings`** removed from Remnawave Settings model (request and response)
|
||||
|
||||
|
||||
|
||||
### API Changelog 2.6.4 vs. 2.7.0
|
||||
|
||||
<details>
|
||||
<summary>View changelog</summary>
|
||||
|
||||
#### Removed Endpoints
|
||||
|
||||
- `GET /api/bandwidth-stats/nodes/realtime`
|
||||
- `POST /api/auth/oauth2/tg/callback`
|
||||
- `GET /api/sub/outline/{shortUuid}/{type}/{encodedTag}`
|
||||
|
||||
#### New Endpoints
|
||||
|
||||
- `POST /api/ip-control/fetch-users-ips/{nodeUuid}` — fetch per-user IPs
|
||||
- `GET /api/ip-control/fetch-users-ips/result/{jobId}` — get fetch results
|
||||
- `POST /api/users/resolve` — resolve user by any identifier
|
||||
- `GET /api/system/stats/recap` — system recap
|
||||
- `GET /api/metadata/node/{uuid}` — get node metadata
|
||||
- `PUT /api/metadata/node/{uuid}` — upsert node metadata
|
||||
- `GET /api/metadata/user/{uuid}` — get user metadata
|
||||
- `PUT /api/metadata/user/{uuid}` — upsert user metadata
|
||||
- `GET /api/node-plugins` — list all plugins
|
||||
- `GET /api/node-plugins/{uuid}` — get plugin
|
||||
- `POST /api/node-plugins` — create plugin
|
||||
- `PATCH /api/node-plugins` — update plugin
|
||||
- `DELETE /api/node-plugins/{uuid}` — delete plugin
|
||||
- `POST /api/node-plugins/actions/clone` — clone plugin
|
||||
- `POST /api/node-plugins/actions/reorder` — reorder plugins
|
||||
- `POST /api/node-plugins/executor` — execute commands on nodes
|
||||
- `GET /api/node-plugins/torrent-blocker` — get reports
|
||||
- `GET /api/node-plugins/torrent-blocker/stats` — get reports stats
|
||||
- `DELETE /api/node-plugins/torrent-blocker` — truncate reports
|
||||
|
||||
---
|
||||
|
||||
#### Removed `cpuCount`, `cpuModel`, `totalRam`, `xrayVersion`, `nodeVersion` from Node response + added `versions`, `system`
|
||||
|
||||
- Removed: `cpuCount`, `cpuModel`, `totalRam`, `xrayVersion`, `nodeVersion`
|
||||
- Added: `versions` (nullable object with `xray` and `node` strings), `system` (nullable `NodeSystem` object), `activePluginUuid`
|
||||
- Changed: `xrayUptime` type from `string` to `number`, `usersOnline` type from `nullable(number)` to `number`
|
||||
|
||||
Affected endpoints:
|
||||
|
||||
- `GET /api/nodes`
|
||||
- `PATCH /api/nodes`
|
||||
- `POST /api/nodes`
|
||||
- `POST /api/nodes/actions/reorder`
|
||||
- `GET /api/nodes/{uuid}`
|
||||
- `POST /api/nodes/{uuid}/actions/disable`
|
||||
- `POST /api/nodes/{uuid}/actions/enable`
|
||||
|
||||
---
|
||||
|
||||
#### Removed `subLastOpenedAt`, `subLastUserAgent` + added `MONTH_ROLLING` to `trafficLimitStrategy` enum in User response
|
||||
|
||||
Affected endpoints:
|
||||
|
||||
- `GET /api/users`
|
||||
- `PATCH /api/users`
|
||||
- `POST /api/users`
|
||||
- `GET /api/users/{uuid}`
|
||||
- `GET /api/users/by-id/{id}`
|
||||
- `GET /api/users/by-email/{email}`
|
||||
- `GET /api/users/by-username/{username}`
|
||||
- `GET /api/users/by-short-uuid/{shortUuid}`
|
||||
- `GET /api/users/by-tag/{tag}`
|
||||
- `GET /api/users/by-telegram-id/{telegramId}`
|
||||
- `POST /api/users/{uuid}/actions/disable`
|
||||
- `POST /api/users/{uuid}/actions/enable`
|
||||
- `POST /api/users/{uuid}/actions/reset-traffic`
|
||||
- `POST /api/users/{uuid}/actions/revoke`
|
||||
|
||||
---
|
||||
|
||||
#### Added `MONTH_ROLLING` to `trafficLimitStrategy` enum in Subscription response
|
||||
|
||||
Affected endpoints:
|
||||
|
||||
- `GET /api/sub/{shortUuid}/info`
|
||||
- `GET /api/subscriptions`
|
||||
- `GET /api/subscriptions/by-short-uuid/{shortUuid}`
|
||||
- `GET /api/subscriptions/by-short-uuid/{shortUuid}/raw` (also removed `subLastOpenedAt`, `subLastUserAgent`)
|
||||
- `GET /api/subscriptions/by-username/{username}`
|
||||
- `GET /api/subscriptions/by-uuid/{uuid}`
|
||||
|
||||
---
|
||||
|
||||
#### Removed `tgAuthSettings` from Remnawave Settings
|
||||
|
||||
- `GET /api/remnawave-settings` — removed from response
|
||||
- `PATCH /api/remnawave-settings` — removed from response and request
|
||||
|
||||
---
|
||||
|
||||
#### RAW subscription response — `rawHosts` replaced with `resolvedProxyConfigs`
|
||||
|
||||
`GET /api/subscriptions/by-short-uuid/{shortUuid}/raw` — the `rawHosts` array is replaced with `resolvedProxyConfigs`. The flat host object is now a typed `ResolvedProxyConfig` structure:
|
||||
|
||||
- `protocol` + `protocolOptions` (discriminated: `vless` / `trojan` / `shadowsocks`)
|
||||
- `transport` + `transportOptions` (discriminated: `tcp` / `ws` / `xhttp` / `httpupgrade` / `grpc` / `kcp`)
|
||||
- `security` + `securityOptions` (discriminated: `tls` / `reality` / `none`)
|
||||
- `streamOverrides` (`finalMask`, `sockopt`)
|
||||
- `mux`
|
||||
- `clientOverrides` (`shuffleHost`, `mihomoX25519`, `serverDescription`, `xrayJsonTemplate`)
|
||||
- `metadata` (`uuid`, `tag`, `inboundTag`, `configProfileUuid`, `isDisabled`, `isHidden`, `viewPosition`, `remark`, `vlessRouteId`, `rawInbound`, `excludeFromSubscriptionTypes`)
|
||||
|
||||
Old flat fields (`password`, `sni`, `alpn`, `fingerprint`, `host`, `network`, `path`, `publicKey`, `shortId`, `spiderX`, `tls`, `rawSettings`, `additionalParams`, `xHttpExtraParams`, `muxParams`, `sockoptParams`, `encryption`, `flow`, `dbData`, etc.) are removed.
|
||||
|
||||
---
|
||||
|
||||
#### Other changes
|
||||
|
||||
- `GET /api/auth/status` — removed required property `tgAuth` from authentication response
|
||||
- `GET /api/ip-control/fetch-ips/result/{jobId}` — `ips` items type changed from `string` to `object` (`{ ip, lastSeen }`)
|
||||
- `GET /api/system/health` — replaced `pm2Stats` with `runtimeMetrics`
|
||||
- `GET /api/system/stats` — removed `cpu/physicalCores`, `memory/active`, `memory/available`
|
||||
|
||||
</details>
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.6.4" date="25 February 2026">
|
||||
|
||||
- hotfix: Mihomo and hidden hosts (hidden by default)
|
||||
- feat: Xray-Json Advanced: `addVirtualHostAsOutbound` – [docs](https://docs.rw/docs/learn/xray-json-advanced)
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.6.3" date="25 February 2026">
|
||||
|
||||
- **hotfix: missing host with enabled "Serve Json At The Base Path" and Xray-Json Advanced**
|
||||
- feat: additional Xray-Json Advanced options: `useHostRemarkAsTag`, `useHostTagAsTag`. [Docs](https://docs.rw/docs/learn/xray-json-advanced)
|
||||
- feat: special Remnawave directives for Mihomo templates: `remnawave.includeHiddenHosts: true`
|
||||
- feat: new Hosts option — "Exclude Host From Specific Subscription Types" (Host Card → Advanced)
|
||||
- feat: new SRR option (responseModifications) — `ignoreServeJsonAtBaseSubscription`
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.6.2" date="24 February 2026">
|
||||
|
||||
- feat: "Xray-Json – Advanced" – multiple outbounds in client xray-json, [documentation](https://docs.rw/docs/learn/xray-json-advanced)
|
||||
- feat: view, drop user connections from any nodes (Users → User Card → More Actions → **Show sessions**)
|
||||
- ...other minor changes
|
||||
|
||||
:::warning
|
||||
Remnawave Node v2.6.0 or higher is required. To access additional features like IP Management — in Remnawave Node `docker-compose.yml` you **must** add under remnanode service:
|
||||
|
||||
```yaml
|
||||
cap_add:
|
||||
- NET_ADMIN
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.6.1" date="16 February 2026">
|
||||
|
||||
- feat: add `ignoreHostXrayJsonTemplate` flag in Response Rules (SRR)
|
||||
- fix: dynamic outline conf
|
||||
- feat: separate page for snippets
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.6.0" date="30 January 2026">
|
||||
|
||||
- New webhook event: `service.subpage_config_changed`. Emitted when subpage config created, updated or deleted.
|
||||
- Bulk actions for Nodes, endpoint: [/api/nodes/bulk-actions](https://docs.rw/api/#tag/nodes-controller/POST/api/nodes/bulk-actions)
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.5.7" date="21 January 2026">
|
||||
|
||||
- Generic Oauth2 auth method
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.5.6" date="21 January 2026">
|
||||
|
||||
- NodeJS v24
|
||||
- Fix: bulk and cron reset user traffic
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.5.5" date="17 January 2026">
|
||||
|
||||
- hotfix: bulk revoke subscription
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.5.4" date="17 January 2026">
|
||||
|
||||
- add KeyCloak as OAuth2 Provider
|
||||
- add Prizrak-Box to extended Mihomo Clients
|
||||
- Fix: OpenAPI schema date formats in bandwidth-stats route
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.5.3" date="9 January 2026">
|
||||
|
||||
- frontend: fix Config & Inbound selection in Node creation card
|
||||
- backend: fix Xray-json additional host properties
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.5.2" date="8 January 2026">
|
||||
|
||||
- Backend: hotfix for empty overrides in external squads
|
||||
- Frontend: config profile selection in Node Card
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.5.1" date="7 January 2026">
|
||||
|
||||
- Hotfix: default custom remarks for External Squads
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.5.0" date="7 January 2026">
|
||||
|
||||
- `scope` in webhook, OpenAPI models for webhook, refer to updated [docs](https://docs.rw/docs/features/webhooks)
|
||||
- [API changes](https://docs.rw/blog/api-changelog/v244-v250)
|
||||
- Custom remarks for: HWID Max Devices Exceeded, HWID Not Supported
|
||||
- Template Variables support in `maxDevicesAnnounce`
|
||||
- Revoke subscription: allow to revoke only connection passwords
|
||||
- ...other minor UI changes
|
||||
|
||||
:::warning
|
||||
Recommended Node version — **v2.5.0**.
|
||||
:::
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.4.4" date="22 December 2025">
|
||||
|
||||
- Subpage Builder: clone App, enhanced subpage config import, other UI fixes
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.4.3" date="20 December 2025">
|
||||
|
||||
- Move some of .env variables to Subpage Builder: `META_TITLE`, `META_DESCRIPTION`, `SUBSCRIPTION_UI_DISPLAY_RAW_KEYS`
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.4.2" date="20 December 2025">
|
||||
|
||||
- iOS Modal/Drawer header offset
|
||||
- Fix: Subpage Config — appname validation
|
||||
- ...other minor UI fixes
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.4.0" date="20 December 2025">
|
||||
|
||||
:::warning
|
||||
Always make **backup** before updating.
|
||||
:::
|
||||
|
||||
- **New UI**: all charts across dashboard (Nodes → Statistics, Node Card → Show usage, User Card → Show usage)
|
||||
- **API Changes**: refactor stat routes. Before updating check up [API Changelog](https://docs.rw/blog/api-changelog/v232-v240)
|
||||
- Brand new **Subscription Page Builder**. New app-config format, full i18n with builder, separate app-configs for external squads and much more.
|
||||
- ...other minor changes
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.3.2" date="9 December 2025">
|
||||
|
||||
- HWID Inspector: HWID top users table
|
||||
- **Rescue CLI**: truncate (clean all data) from HWID or SRH tables (`docker exec -it remnawave cli`)
|
||||
- Fix: adjust time ranges for "Online Now" badge (60s → 30s)
|
||||
- ...other: restore Internal Squads in Telegram notifications, correct OpenAPI schema for "Encrypt Cryptolink" endpoint
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.3.1" date="8 December 2025">
|
||||
|
||||
- New: [fine-tuned notifications](https://docs.rw/docs/features/fine-tuned-notifications)
|
||||
- Fix: empty `/api/subscription` response
|
||||
- Fix: bulk reset race condition
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.3.0" date="7 December 2025">
|
||||
|
||||
:::warning
|
||||
Обязательно сделайте бекап перед обновлением. Обновление содержит серьёзные изменения в API.
|
||||
:::
|
||||
|
||||
Версия панели (2.3.0) требует обновить ноды до версии 2.3.0.
|
||||
|
||||
**Основные изменения:**
|
||||
|
||||
- Полный контроль flow для VLESS-инбаундов
|
||||
- Внешние сквады: переопределение настроек HWID, переопределение «примечаний» (по статусам)
|
||||
- Возможность изменить порядок: внутренние сквады, внешние сквады, профили, шаблоны
|
||||
- Поддержка balancers в сниппетах
|
||||
- Табличный вид отображения списка нод
|
||||
- ZSTD-сжатие конфига перед отправкой на ноды
|
||||
- Новая `.env` переменная — `REDIS_SOCKET` (подключение Redis/Valkey через unix-сокет)
|
||||
- Выбрать индивидуальный Xray-Json для каждого хоста (на основе шаблонов)
|
||||
- Исключить хост из определённых внутренних сквадов
|
||||
- «Теги» для нод (можно указать несколько тегов)
|
||||
- Массовое изменение активного профиля/инбаундов у нод (мультивыбор)
|
||||
- Новая `.env` переменная: `USER_USAGE_IGNORE_BELOW_BYTES`
|
||||
- Новая `.env` переменная: `SERVICE_DISABLE_USER_USAGE_RECORDS`
|
||||
- Рефактор: очереди, фоновые задачи, оптимизация таблиц в базе данных
|
||||
- ...прочие QoL изменения и исправления
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.2.6" date="6 November 2025">
|
||||
|
||||
- Override response headers with External Squads
|
||||
- Add gRPC support
|
||||
- Branding: set colored brand name
|
||||
- Webhook URL: now supports multiple URLs (separated by commas)
|
||||
- Users table: filtering, search by External Squad
|
||||
- Fix: iOS floating header
|
||||
- Fix: missing background in Metrics
|
||||
- ...other minor changes
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.2.5" date="2 November 2025">
|
||||
|
||||
- Hotfix: missing host creation button (if there is no hosts)
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.2.4" date="2 November 2025">
|
||||
|
||||
- Fix: Xray Json (Serve at base path) incorrect template response
|
||||
- Fix: VLESS Encryption — incorrect decryption parsing logic
|
||||
- New: Vazirmatn font for Persian language and Noto Sans SC for Chinese
|
||||
- New: Host overrides in External Squads
|
||||
- New: Reset Node Traffic
|
||||
- More strict passkey (register + auth) settings
|
||||
- **New: help action button with detailed articles on Hosts, Config Profiles, Internal and External Squads sections**
|
||||
- New: view computed Config Profile (Config Profile + applied snippets)
|
||||
- Monkey patch incorrect **serverNames** array before saving changes
|
||||
- Refactor some layouts in frontend
|
||||
- ...other minor changes
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.2.3" date="27 October 2025">
|
||||
|
||||
- Hotfix: `/json` — incorrect response body
|
||||
|
||||
:::warning
|
||||
In previous versions, when HWID was enabled, the panel forcibly removed the **profile-web-page-url** header, which is responsible for displaying the subscription link in client applications. This behavior from the panel has proven to be incorrect in practice. In this version, Remnawave will no longer forcibly hide this header when HWID is enabled.
|
||||
|
||||
**If you're using HWID together with a crypto link (Happ), don't forget to disable the display of this header in the Subscription → Settings section. Look for the "Profile Webpage URL" option.**
|
||||
:::
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.2.2" date="26 October 2025">
|
||||
|
||||
- Hotfix: 5xx errors while updating user **by username**
|
||||
- Fix: Incorrect response content type with "serve json at base path" option (or /json)
|
||||
- More clear errors while adding passkey device
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.2.0" date="26 October 2025">
|
||||
|
||||
Крупнейшее обновление с момента выхода v2.x.
|
||||
|
||||
[→ Ознакомиться с описанием обновления](https://telegra.ph/Remnawave-v220-10-25) **[RU]**
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.1.19" date="12 October 2025">
|
||||
|
||||
- **Infra Billing:** Multiselect in Infra Billing Nodes table (quickly change next billing date for multiple nodes)
|
||||
- **Infra Billing:** Quick update billing date button (move node to the next billing cycle with one click)
|
||||
- **Infra Billing:** Update Infra Billing Node request schema changed
|
||||
- Fix: Hosts, Nodes cards margins in mobile view
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.1.18" date="11 October 2025">
|
||||
|
||||
- Add support for **mldsa65Seed** & verify
|
||||
- **Add full support for Vless Encryption**
|
||||
- Fix: incorrect boolean assignment in **ais** (base64)
|
||||
- Return **serverDescription** for **FlClashX**
|
||||
- Fix: ALPN in xray-json
|
||||
- **Add option to link nodes to Hosts** (visual assignment only)
|
||||
- Frontend: new keypairs generators: MLDSA65, ML-KEM768
|
||||
- Frontend: fix incorrect squads assignment in bulk actions
|
||||
- Frontend: Host card now inside Drawer (instead of Modal)
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.1.17" date="2 October 2025">
|
||||
|
||||
- Frontend: fix incorrect loader position
|
||||
- Frontend: fix aggressive reloads
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.1.16" date="30 September 2025">
|
||||
|
||||
- Backend: added new object to GetSubscriptionRequestHistoryStats response
|
||||
- Frontend: hide header with scroll
|
||||
- Frontend: SRH Inspector — new chart
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.1.15" date="29 September 2025">
|
||||
|
||||
- Main title and logo customization, new .env params: `BRANDING_TITLE`, `BRANDING_LOGO_URL`
|
||||
- Small UI fixes in Subscription Request History drawer
|
||||
- New: shuffleHost, mihomoX25519 in Host Card
|
||||
- Add UUID column to Users table (search, sorting)
|
||||
- Allow spaces in Config Profile and Internal Squad names
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.1.14" date="23 September 2025">
|
||||
|
||||
- fix: telegramId incorrect search behaviour
|
||||
- fix: cleanup subscription request history
|
||||
- fix: incorrect link in profile-webpage-url header
|
||||
- allow to update user by username
|
||||
- allow to pass own UUID in user creation
|
||||
- update Happ CryptoLink to v3
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.1.13" date="15 September 2025">
|
||||
|
||||
- **HWID Inspector**, view stats for your HWID devices, full featured table (list, search, sort, filter) available
|
||||
- API endpoint: [Get all HWID devices](https://remna.st/api/#tag/hwid-user-devices-controller/get/api/hwid/devices)
|
||||
- API endpoint: [Get HWID Device stats](https://remna.st/api/#tag/hwid-user-devices-controller/get/api/hwid/devices/stats)
|
||||
- fix: ip parsing in subscription requests
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.1.12" date="15 September 2025">
|
||||
|
||||
- Minor UI fixes in frontend
|
||||
- [New webhook events related to HWID devices (added, deleted)](https://github.com/remnawave/backend/blob/main/libs/contract/constants/events/events.ts#L21)
|
||||
- add allowInsecure to Host
|
||||
- add User Subscription Request History, up to 24 latest records will be stored
|
||||
- [new API endpoint to delete all user HWID devices](https://remna.st/api/#tag/hwid-user-devices-controller/post/api/hwid/devices/delete-all)
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.1.9" date="6 September 2025">
|
||||
|
||||
- Restore curl in Dockerfile
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.1.8" date="3 September 2025">
|
||||
|
||||
**Backend:**
|
||||
|
||||
- `/api/system/tools/x25519/generate` — generate 30 x25519-keypairs
|
||||
- Bulk Actions now supports mass HWID modifications
|
||||
- `/raw` subscription schema and path changed. New path: `/api/subscriptions/by-short-uuid/{shortUuid}/raw`
|
||||
- Node version downgraded to 22.18.0
|
||||
- Change memory allocator from jemalloc to mimalloc
|
||||
- Upgrade deps (PrismaORM 6.15.0, etc)
|
||||
|
||||
**Frontend:**
|
||||
|
||||
- Queues (sidebar) now hidden by default. Toggle: `Cmd/Ctrl + Shift + J`
|
||||
- Fix incorrect tag assignment in Host card section
|
||||
- Add supports for HWID mass actions
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.1.7" date="30 August 2025">
|
||||
|
||||
- new endpoints in [Subscriptions Controller](https://remna.st/api#tag/subscriptions-controller): get subscription info by short uuid and by uuid.
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.1.6" date="29 August 2025">
|
||||
|
||||
:::warning
|
||||
`/raw` subscription route response changed.
|
||||
|
||||
Previous: `{ "user": {}... }`
|
||||
New: `{ "response": { "user": {}... } }`
|
||||
:::
|
||||
|
||||
- fix: subscription link is not shown with HWID enabled (only for admin dashboard)
|
||||
- fix: infra billing incorrect ranges
|
||||
- fallback hosts (expired, limited, disabled) now use vless instead of trojan
|
||||
- refactor: change infra billing notifications texts
|
||||
- minor UI fixes in frontend
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.1.5" date="26 August 2025">
|
||||
|
||||
- Hotfix for incorrect migration behaviour on clean database
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="2.1.4" date="26 August 2025">
|
||||
|
||||
**Backend:**
|
||||
|
||||
- Add indexes to database
|
||||
- Add **tId** for internal use (speed up config generation & pagination)
|
||||
- Add option to **force** restart all nodes (Xray Core restart guaranteed, hash-checking will be skipped)
|
||||
- raw subscription keys will not be returned anymore in `/info` route if HWID enabled
|
||||
- add _bytes_ response in `/info` and `browser-json` of subscription
|
||||
- fix bug with `@nestjstools/messaging`, which was cause of memory leak with Redis/Valkey
|
||||
- Redis/Valkey DB will be completely flushed with panel start
|
||||
- Stash Subscription Generator now uses MihomoService under hood (allows Vless Reality with Stash)
|
||||
- Add `UTC` mark in Telegram notifications
|
||||
- **Add support for coming Vless-Route** option in Xray Core
|
||||
- Fix: clearing clients array from Xray Config before adding users
|
||||
- Fix: HWID Devices was not registered in database if HWID Detection is off for specific user
|
||||
- GetAllInbounds, GetInboundByProfileUuid — now returns activeSquads uuids
|
||||
|
||||
**Frontend:**
|
||||
|
||||
- Fix: input in Host card resets between tabs
|
||||
- Add unsaved changes warnings in Config Profile editor
|
||||
- Modify Restart all nodes action button, add modal with restart type selection (graceful, force)
|
||||
- Add _Inbounds With Active Squads_ drawer in Config Profiles section
|
||||
- Minor UI improvements and fixes
|
||||
|
||||
</ReleaseEntry>
|
||||
168
docs/changelog/remnawave-subscription-page.mdx
Normal file
@@ -0,0 +1,168 @@
|
||||
---
|
||||
sidebar_position: 3
|
||||
title: Subscription Page
|
||||
description: 'Changelog for Remnawave Subscription Page'
|
||||
hide_title: true
|
||||
hide_table_of_contents: true
|
||||
---
|
||||
|
||||
# Subscription Page
|
||||
|
||||
<ReleaseEntry version="7.1.8" date="8 March 2026">
|
||||
|
||||
### New features
|
||||
|
||||
`MARZBAN_LEGACY_DROP_REVOKED_SUBSCRIPTIONS` .env variable.
|
||||
|
||||
`true` – drop requests from legacy subscription urls, if `subRevokedAt` field is not `null` (subscription was revoked at least once).
|
||||
`false` - **default** value, the same behavior as before.
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="7.1.7" date="30 January 2026">
|
||||
|
||||
- Pass multiple Marzban Secret keys
|
||||
|
||||
```
|
||||
MARZBAN_LEGACY_SECRET_KEY=key1,key2,key3
|
||||
```
|
||||
|
||||
:::warning
|
||||
Minimum panel version — v2.5.x or higher
|
||||
:::
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="7.1.6" date="21 January 2026">
|
||||
|
||||
- Bump NodeJS to v24.13
|
||||
- ...other minor changes
|
||||
|
||||
:::warning
|
||||
Minimum panel version — v2.5.x or higher
|
||||
:::
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="7.1.4" date="17 January 2026">
|
||||
|
||||
- change health check endpoint
|
||||
- add additional headers to ignore
|
||||
- fail fast on invalid subpage config during startup
|
||||
|
||||
:::warning
|
||||
Minimum panel version — v2.5.x or higher
|
||||
:::
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="7.1.2" date="11 January 2026">
|
||||
|
||||
- hotfix: headers
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="7.1.1" date="11 January 2026">
|
||||
|
||||
- fix: remove headers filtering
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="7.1.0" date="7 January 2026">
|
||||
|
||||
- Hide `Get Link` (Show QR) button via subpage config
|
||||
- New button types: `HAPP_CRYPT3_LINK`, `HAPP_CRYPT4_LINK`
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="7.0.7" date="28 December 2025">
|
||||
|
||||
- Fix: iOS18 cards
|
||||
- Fix: Scrollbar for language selector
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="7.0.5" date="22 December 2025">
|
||||
|
||||
- New: **App Icons**
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="7.0.4" date="20 December 2025">
|
||||
|
||||
- Move some of .env variables to Subpage Builder: `META_TITLE`, `META_DESCRIPTION`, `SUBSCRIPTION_UI_DISPLAY_RAW_KEYS`
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="7.0.3" date="20 December 2025">
|
||||
|
||||
- Fix: fallback platform selection
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="7.0.0" date="20 December 2025">
|
||||
|
||||
:::warning
|
||||
v7.0.0 (or higher) requires Remnawave v2.4.0 (or higher).
|
||||
|
||||
**Breaking change**: API token now is required.
|
||||
.env variable: `REMNAWAVE_API_TOKEN`.
|
||||
:::
|
||||
|
||||
- New app-config format
|
||||
- Dynamic App Config loading from Remnawave
|
||||
- Disable/enable any languages as you want. English now is not necessary.
|
||||
- Add as many blocks as you want, customize svg icons and more. **Check up Subscription Page Builder in Remnawave.**
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="6.4.2" date="11 December 2025">
|
||||
|
||||
- Fonts: Vazirmatn for Persian, NotoSans SC for Chinese
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="6.4.1" date="10 December 2025">
|
||||
|
||||
- Display **Connection Keys** on Subscription Page
|
||||
|
||||
:::info
|
||||
This feature is **disabled by default**. It must be enabled via .env/environment variables.
|
||||
|
||||
Checkout docs: [Display Raw Keys](https://docs.rw/docs/install/subscription-page/display-raw-keys)
|
||||
:::
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="6.4.0" date="9 December 2025">
|
||||
|
||||
- New design
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="6.3.0" date="7 December 2025">
|
||||
|
||||
- Part of Remnawave v2.3.0 release
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="6.1.0" date="24 November 2025">
|
||||
|
||||
- Add French language support
|
||||
- Add "Check Panel connection on application start"
|
||||
- Log panel url and custom_sub_prefix on application start for debug purposes
|
||||
- ...other minor changes
|
||||
|
||||
</ReleaseEntry>
|
||||
|
||||
<ReleaseEntry version="6.0.6" date="15 September 2025">
|
||||
|
||||
- Small fixes for IP Address parsing and handling
|
||||
- Add support for **Cloudflare Zero Trust** auth, new .env variables:
|
||||
|
||||
```
|
||||
CLOUDFLARE_ZERO_TRUST_CLIENT_ID=""
|
||||
CLOUDFLARE_ZERO_TRUST_CLIENT_SECRET=""
|
||||
```
|
||||
|
||||
</ReleaseEntry>
|
||||
79
docs/clients.mdx
Normal file
@@ -0,0 +1,79 @@
|
||||
---
|
||||
sidebar_position: 8
|
||||
title: 📱 Clients
|
||||
hide_title: true
|
||||
hide_table_of_contents: true
|
||||
description: 'A comprehensive list of proxy clients that work with Remnawave across all platforms - Android, iOS, Windows, macOS, and Linux. Find the perfect client for your needs.'
|
||||
image: '/clients/clients-preview.webp'
|
||||
---
|
||||
|
||||
<HeroSection
|
||||
title="Clients"
|
||||
subtitle="A comprehensive list of proxy clients that work with Remnawave. Choose the best client for your platform and preferred proxy core."
|
||||
/>
|
||||
|
||||
<CategoryNav
|
||||
categories={[
|
||||
{ id: 'android', icon: '📱', title: 'Android' },
|
||||
{ id: 'windows', icon: '💻', title: 'Windows' },
|
||||
{ id: 'ios', icon: '🍎', title: 'iOS' },
|
||||
{ id: 'macos', icon: '👛', title: 'macOS' },
|
||||
{ id: 'linux', icon: '🐧', title: 'Linux' }
|
||||
]}
|
||||
/>
|
||||
|
||||
<CategorySection
|
||||
id="android"
|
||||
title="Android"
|
||||
description="Proxy clients for Android devices"
|
||||
icon="📱"
|
||||
columns={3}
|
||||
>
|
||||
<ClientsList platform="android" />
|
||||
</CategorySection>
|
||||
|
||||
<CategorySection
|
||||
id="ios"
|
||||
title="iOS"
|
||||
description="Proxy clients for iOS devices"
|
||||
icon="🍎"
|
||||
columns={3}
|
||||
>
|
||||
<ClientsList platform="ios" />
|
||||
</CategorySection>
|
||||
|
||||
<CategorySection
|
||||
id="windows"
|
||||
title="Windows"
|
||||
description="Proxy clients for Windows"
|
||||
icon="💻"
|
||||
columns={3}
|
||||
>
|
||||
<ClientsList platform="windows" />
|
||||
</CategorySection>
|
||||
|
||||
<CategorySection
|
||||
id="macos"
|
||||
title="macOS"
|
||||
description="Proxy clients for macOS"
|
||||
icon="👛"
|
||||
columns={3}
|
||||
>
|
||||
<ClientsList platform="macos" />
|
||||
</CategorySection>
|
||||
|
||||
<CategorySection
|
||||
id="linux"
|
||||
title="Linux"
|
||||
description="Proxy clients for Linux"
|
||||
icon="🐧"
|
||||
columns={3}
|
||||
>
|
||||
<ClientsList platform="linux" />
|
||||
</CategorySection>
|
||||
|
||||
---
|
||||
|
||||
### ℹ️ Notice
|
||||
|
||||
This list is community-maintained. If you find any broken links or want to add a client, please open a PR on GitHub.
|
||||