@marowi
you can try directly editing the inactive period in the vhost config file and then making that file immutable
and then restart/reload nginx to pick up the change
so far, that shouldn't cause any immediate problems.
you can then try making a change to the site in the enhance panel that you know would force it to recreate that vhost config file, and see how it reacts. it's possible that nothing happens except possibly a warning that it couldn't recreate the file / save the config change, and everything just continues as normal.
if it does cause a problem, then just remove the immutable bit from the file permissions, (possibly restart/reload nginx - this step may not be needed) and then you should be able to make changes in the panel that will recreate the vhost config again and you're just back to where you are now.
any potential downtime should be well under 1 minute, you could also do this on a test server to see if it works without any production downtime.
if it all works fine, then the only downside to doing this is if you do need to make changes to that vhost in future, you have to keep remembering to remove the immutable bit, make the change in the panel, and then re-edit the fastcgi cache inactive time, make the file immutable again, and then reload/restart nginx.
on the flip side, if it does work without any problems, then it makes a case for a feature request to be able to set the fastcgi-cache inactive time per website via a setting in the panel alongside the other nginx cache settings.
removing the hassle of constantly removing the immutable bit, editing, and then re-applying the immutable bit on the config file.
